【実務・中級編】 レイヤー2スイッチのストア&フォワード方式とカットスルー方式 – インフラ・物理&L2/L3ネットワーク基礎実践ガイド

0.1秒の遅延がシステムを殺す:L2スイッチの「ストア&フォワード」と「カットスルー」を実務目線で徹底解剖する

ネットワークの向こう側で何が起きているか、考えたことはあるでしょうか。

Web APIのレスポンスタイムをミリ秒単位で削り出し、高頻度トレーディング(HFT)やリアルタイム・ストリーミング基盤のチューニングに日夜奔走するWebエンジニアやインフラエンジニアの皆さん。アプリケーション層のコードをどれだけ最適化しても、そのパケットを物理世界で最初に受け止める「レイヤー2スイッチ」の挙動を知らなければ、あなたのシステムはまだ「運任せのブラックボックス」の上を走っていることになります。

今回は、スイッチングハブ(L2スイッチ)の心臓部である「ストア&フォワード(Store and Forward)」と「カットスルー(Cut-Through)」という2つの転送方式にスポットを当てます。教科書的な定義のなぞり合いはやめにしましょう。現場のシニアエンジニアが、パケットの気持ちになり、そして障害の現場から得たリアルな知見を交えて、この2つの挙動の違いと実務での選び方を徹底的に解説します。

—

1. パケットがスイッチを通過する瞬間のリアル

スイッチの役割はシンプルです。あるポートに飛び込んできたイーサネットフレームを、宛先MACアドレスを見て適切な別のポートへ「転送(スイッチング)」すること。しかし、この「どうやって転送するか」のポリシーにおいて、L2スイッチのメーカーや機種選定の哲学が分かれます。

フレームが物理インターフェース(SFP+やRJ-45)のレシーバに到達した瞬間、L2スイッチのASIC(専用プロセッサ)は2つの選択を迫られます。

1. 全部読んでから安全確認する(ストア&フォワード)
2. 宛先だけチラ見して、即座に投げ飛ばす(カットスルー)

この選択が、レイテンシ(遅延)とパケットロッドのトレードオフを決定づけます。

—

2. ストア&フォワード方式(Store and Forward)

標準仕様とアーキテクチャの基本

IEEE 802.3で規定されるイーサネットの原則に忠実な、最も一般的で信頼性の高い方式です。

スイッチは、受信ポートにフレームの最後のビットが到達するまで(つまり、フレーム全体をメモリバッファに格納するまで)、一切の転送処理を行いません。フレーム全体がメモリに収まった段階で、以下の処理を実行します。

  • FCS(Frame Check Sequence)の検証: フレーム末尾にあるCRCエラーチェックを行い、途中のノイズなどでデータが破損していないか厳密に確認する。
  • 不正サイズの検出: 64バイト未満の「ジャイアント/ランツ」と呼ばれる不正なミニフレームや、1518バイト(またはジャンボフレーム設定時のサイズ)を超えるオーバーサイズフレームを即座に破棄(ドロップ)する。

シーケンス・処理フロー

[送信端末] 
    │
    │ (フレーム送信:数KB)
    ▼
[L2スイッチ: 受信ポート]
    │
    │──(1) フレームの全データをバッファメモリに蓄積...
    │──(2) FCS(CRC)を計算し、破損がないかチェック
    │──(3) MACアドレステーブルと照合
    │
    ▼ (エラーなし、宛先確定)
[L2スイッチ: 送信ポート] ──> [受信端末]

メリットとデメリット

  • メリット: 壊れたパケットやコリジョン起因の不正なフラグメントを完全にフィルタリングするため、無駄なトラフィックを対向セグメントに伝搬させない。データ完全性が極めて高い。
  • デメリット: フレーム長に比例して処理遅延(レイテンシ)が増加する。例えば、1500バイトのフルサイズフレームを1Gbps回線で受け取る場合、フレーム全体を受け切るだけで約12マイクロ秒の遅延が固定で発生します。

—

3. カットスルー方式(Cut-Through)

超高速化の代償

「正確性よりもスピードだ。細かいエラーチェックは上位層(TCPやアプリケーション)に任せろ」という、スパルタンな思想に基づいた方式です。

カットスルー方式では、スイッチはフレーム全体の到着を待ちません。宛先MACアドレス(イーサネットヘッダーの先頭から6〜12バイト目)さえ読み取れれば、フレームの末尾がまだケーブル上に流れている最中でも、即座に出力ポートへ向けた転送(フォワーディング)を開始します。

バリエーション:フラグメントフリー方式

カットスルーの亜種として、コリジョン(衝突)の検知に必要な最低限のサイズである「最初の64バイト」だけは受信してから転送するフラグメントフリー(Fragment-Free)方式もあります。これにより、イーサネットの初期不良でよくある「ゴミクズのような最小サイズ未満の破損フレーム」の拡散を防ぎつつ、カットスルーの恩恵(低遅延)をある程度受けることができます。

メリットとデメリット

  • メリット: 圧倒的な低遅延(低レイテンシ)。フレームサイズに関わらず、宛先をデコードするわずか数マイクロ秒(あるいはサブマイクロ秒)で転送を開始するため、HFTや超高負荷なクラスタ間通信において絶大な効果を発揮します。
  • デメリット: エラーフレームの伝搬。途中でCRCが破損しているパケットであっても、宛先MACさえ合っていればそのまま対向機器へ送り出してしまいます。結果として、受信側のNICでパケット破棄が発生し、上位のTCP再送を引き起こす原因になります。また、異なる速度(例: 10Gbpsから1Gbps)へポートを跨ぐ場合、バッファリングが必須となるため、純粋なカットスルーは成立しません(アダプティブ・カットスルー等の複雑な機構が必要になります)。

—

4. 徹底比較:どちらを選ぶべきか?

実務の現場において、ネットワーク機器(Cisco NexusやArista、Juniperなど)のデータシートを読み解く際、この2つの方式の特性を理解しているかどうかがアーキテクトとしての腕の見せ所です。

| 評価項目 | ストア&フォワード (Store and Forward) | カットスルー (Cut-Through) |
| :— | :— | :— |
| レイテンシ | 比較的高い(フレーム長に依存) | 極めて低い(固定かつ最小限) |
| 信頼性(エラー耐性) | 高い(不正パケットを完全遮断) | 低い(破損フレームもそのまま転送) |
| ポート速度混在時の挙動 | 異速度間(10G→1G等)でも完璧に対応 | 困難(バッファリングが不可避) |
| 主な適用領域 | 一般的な企業ネットワーク、データセンターの大部分 | 高頻度取引(HFT)、超低遅延HPC環境 |

—

5. 実務における設定と検証の勘所

現代のエンタープライズ・データセンター向けスイッチ(例: Cisco Nexusシリーズなど)では、デフォルトでカットスルーが有効になっている場合や、ポートの混雑状況に応じて自動で切り替える「アダプティブ・カットスルー」が採用されているケースがあります。

ここでは、実務でトラブルシューティングを行う際、スイッチがどちらのモードで動作しているか、あるいはエラーフレームがどのように扱われているかを確認するためのアプローチを紹介します。

インフラ設定・状態確認のイメージ(Cisco NX-OS系)

# スイッチのグローバル設定モードでカットスルーの状態を確認するコマンド
switch# show switching-mode
Current switching mode: Cut-Through

# ポートごとのエラーカウンタやドロップパケットを確認し、
# カットスルーによる破損パケットの拡散(CRCエラーの波及)が起きていないか精査する
switch# show interface ethernet 1/1
Ethernet1/1 is up
  10Gbe光学トランシーバ接続
  RX
    3215684 unicast packets  0 multicast packets  0 broadcast packets
    0 input errors  0 drop  0 CRC/FCS  <-- ここがゼロであることが重要
  TX
    4125890 unicast packets  0 multicast packets  0 broadcast packets
    0 output errors  0 buffer failures

> シニアからの実務Tips:
> カットスルー環境下で、もし対向サーバーのアプリケーション層(PythonのrequestsやNode.jsのHTTPクライアントなど)で突発的なコネクションタイムアウトやパケットロスが頻発する場合、スイッチのカットスルーが原因で「CRCエラーを含んだ不完全なフレーム」がサーバーNICに到達し、NIC側でハードウェア破棄されているケースを疑ってください。
>
> こうした場合、一時的にスイッチ側でストア&フォワードへ強制固定するか、物理レイアのL1(SFP+トランシーバや光ファイバーケーブルの汚れ・減衰)を疑うのが定石です。

—

6. アプリケーション開発者・インフラ運用者へのインプリケーション

「たかがレイヤー2、されどレイヤー2」。Web APIの設計やマイクロサービスのトポロジー設計において、私たちが書くコードの背後では、ハードウェアレベルのパケット処理が秒間数百万回も行われています。

  • API設計時: レスポンスのペイロードサイズを不必要に巨大化させないこと(MTUやMSSの境界を意識し、1500バイトの通常のイーサネットフレーム内に収めること)は、ストア&フォワード環境下でのバッファ遅延を最小限に抑える上で直結します。
  • インフラ選定時: 「とにかく速いからカットスルーにしよう」と安易に飛びつくのではなく、物理配線の品質(SFPの光パワーやBER:ビット誤り率)が担保されているクリーンなデータセンター環境でのみ、カットスルーの真価が発揮される点を忘れないでください。

ネットワークの基礎であるイーサネットフレームのハンドリング。その一瞬の挙動に思いを馳せることが、障害に強く、かつ秒速のパフォーマンスを叩き出す真のインフラストラクチャを築く第一歩となります。

次回のネットワーク構築やアーキテクチャレビューの際には、ぜひこのL2スイッチの「脳内処理」にまで意識を向けてみてください。

コメント

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