こんにちは。ネットワークの深淵へようこそ。インフラアーキテクトの私です。
Web APIの設計やモダンなクラウドインフラの構築に日々奔走するエンジニアの皆さん、ふと立ち止まって考えてみてほしい。あなたが叩くcurlの向こう側、データセンターのラックに鎮座するL2/L3スイッチのASIC（Application-Specific Integrated Circuit）のなかで、パケットは一体どれほどの超高速で処理されているのだろうか。
「MACアドレスを引く」「L4のACLでパケットをドロップする」。これらはインフラエンジニアにとって日常茶飯事の操作だ。しかし、その裏側でハードウェアがどのようにメモリを叩き、ミリ秒どころかナノ秒単位の決断を下しているのかを知る者は意外と少ない。
今回は、スイッチングの心臓部である CAM（Content Addressable Memory） と TCAM（Ternary CAM） のハードウェアアーキテクチャにスポットを当て、パケットがasicの門を叩いてから転送されるまでのリアルなドラマを紐解いていこう。現場のトラブルシューティングで役立つ実践的な知見も交えて解説する。
—
1. CAMとTCAMの基本概念：なぜ「検索」がハードウェアのボトルネックになるのか
ソフトウェアの世界（例えばPythonの辞書やデータベース）であれば、O(1)のハッシュ参照やBツリーインデックスを使えば数十万件のレコードも一瞬で引ける。しかし、GbpsからTbpsの線を流れてくるイーサネットフレームに対し、CPUがソフトウェア処理でルーティングやMACアドレッシングを行っていたのでは、帯域に全く追いつかない。
ここに、ハードウェア（ASICやFPGA）による並列検索の必要性がある。
二値の世界：CAM（Content Addressable Memory）
通常のRAMは「アドレス（番地）」を指定して「データ」を取り出す。これに対し、CAMはその逆をやノースだ。「データ（例: MACアドレス）」を入力すると、メモリ内部のすべてのエントリが一斉に比較され、それが格納されている「アドレス」とヒットしたという事実を返す。
- 格納する値:
0または1の完全一致（Exact Match） - 主な用途: L2スイッチのMACアドレステーブル（CAMテーブル）
MACアドレスは48ビットの完全一致の世界だ。「このMACシグネチャを持つ端末はどのポートにいるか？」を1クロックサイクルで引き出すために、CAMはこの世に生を受けた。
三値の世界：TCAM（Ternary Content Addressable Memory）
しかし、ネットワークの現実は「完全一致」だけでは回らない。ルーティングのプレフィックス長マッチ（例: 192.168.1.0/24）や、L4のアクセスリスト（ACL）における「ポート番号の範囲指定」や「ワイルドカードマスク」を処理する必要がある。
ここで登場するのが、0 と 1 に加えて X（Don’t Care / ワイルドカード） を扱える TCAM だ。
- 格納する値:
0、1、X（ワイルドカード） - 主な用途: L3ルーティングテーブル（FIB）、QoS分類、ACL（Access Control List）
—
2. 内部構造の物理的メカニズム：なぜTCAMは「電気を食う怪物」なのか
ここで、シニアとして少しハードウェア寄りの泥臭い話をしよう。なぜCisco CatalystやAristaのハイエンドスイッチはあんなにファンがうるさく、電力を消費するのか。その犯人の一味がTCAMなのだ。
従来のRAM vs CAM vs TCAM の比較
| 項目 | 通常のRAM (SRAM/DRAM) | CAM (二値) | TCAM (三値) |
| :— | :— | :— | :— |
| 検索方式 | アドレス指定による読み出し | 全エントリとの一斉比較 (0/1) | 全エントリとの一斉比較 (0/1/X) |
| 比較の仕組み | デコーダー回路 | 各セルに比較回路（Comparator）を内蔵 | 各セルに比較用トランジスタを倍増（0/1判定 ＋ Xマスク） |
| 消費電力・発熱 | 極めて低い | 高い | 極めて高い |
| 集積度 | 極めて高い | やや低い | 低い（面積を食う） |
CAMやTCAMの検索は、ソフトウェア的なアルゴリズムではなく、「ハードウェアの総当たり戦」だ。
入力された検索キー（Search Key）が、メモリセルに並んだ数千〜数万のエントリと物理的な電気信号として同時に比較される。1クロックで結果が出る代償として、すべての比較回路が一斉にスイッチングするため、膨大なダイナミック消費電力と発熱を発生させる。
—
3. 実務の現場から：CAM/TCAM枯渇とハードウェア制限のトラブルシューティング
Web系からインフラの世界に入ったエンジニアが最初にハマる罠が、この「ハードウェアリソースの枯渇」だ。クラウド（AWSのSecurity Groupなど）ではリソース制限を意識することは少ないが、オンプレミスの物理スイッチやルーターでは、TCAMのエントリ数は有限のシビアなリソースである。
よくある現場の悲劇：「ACLを書きすぎたらルーティングがおかしくなった」
Catalystスイッチなどで、セキュリティ要件を満たすために巨大なACLを次々と投入した結果、突如としてネットワークが不安定になり、ログに次のようなエラーが吐き出される。
%PLATFORM-3-PBR_TCAM_FULL: TCAM allocation failed for policy-map...
%FIB-4-TCAM_WARNING: FIB TCAM utilization has reached 95% threshold.これは、ACLやFIBが共有するTCAMのスライス（Region）が完全に溢れ、新しいルーティングエントリやACLルールがハードウェアに書き込めなくなった状態だ。CPUへフォワーディングがフォールバック（Process Switching）するか、単純にパケットがドロップされるため、インフラ障害に直結する。
対策：SDM（Switch Database Management）テンプレートの調整
Cisco等のスイッチでは、ハードウェアリソースの割り当てをユースケースに応じて変更できる SDMテンプレート という機能が存在する。
例えば、L2中心で動かすのか、L3ルーティングとIPv4/IPv6のACLをフルに載せるのかによって、CAMとTCAMのパーティションを再分割する必要がある。
以下は、Cisco CatalystスイッチにおけるSDMテンプレート変更のCLI設定例だ。
! =====================================================================
! [実務設定例] デュアルスタック環境および大量のACLを考慮したSDMテンプレートの変更
! =====================================================================
! 1. 特権モードへ移行
enable
! 2. グローバルコンフィグレーションモードへ移行
configure terminal
! 3. IPv4/IPv6のルーティングとACLのバランスを最適化したテンプレートを適用
! ※デフォルトからセキュリティ（ACL）重視のプロファイルへ切り替える例
sdm prefer routing advanced
! 4. 設定を反映させるためにスイッチを再起動（ハードウェアのASIC/メモリマッピング変更のため必須）
end
reload> ⚠️ 現場のシニアからの警告（Tips）:
> SDMテンプレートの変更は必ずコールドリロード（再起動）を伴う。本番環境で「ちょっと設定変えてみます」と軽い気持ちで実行すると、全トラフィックが数分間断絶して阿鼻叫叫の地獄絵図になる。メンテナンスウィンドウを確実に確保してから実施すること。
—
4. パケットが流れる瞬間のシーケンス（L2スイッチングの舞台裏）
ここで、宛先MACアドレスを持つフレームがスイッチのポートに飛び込んでから、転送されるまでのシーケンスを整理しよう。ここでCAMがどう関わっているのかがリアルに見えてくる。
[送信元端末]
│
│ (1) Ethernetフレーム送信
▼
[L2スイッチ (Ingress Port)]
│
│ (2) プリアンブル/FCS剥離 ＆ ソースMAC学習
│ └─► 自分のCAMテーブルに [Source MAC ＋ VLAN ID ➔ 入力ポート] を書き込み/更新
│
│ (3) 宛先MACアドレスの抽出
│ └─► 宛先MACを「CAMテーブル」へインプット (1クロック検索)
│
├─► Hitする場合:
│ └─► CAMから「出力ポート（Outgress Port）」を取得し、該当ポートへ転送 (Hardware Forwarding)
│
└─► Missする場合 (未知のユニキャスト / 宛先がCAMにない):
└─► フラッディング (Flooding) ➔ 同一VLAN内の全ポートへブロードキャスト送信この「未知のユニキャスト（Unknown Unicast）」の際にCAMテーブルが埋まっていく。もし悪意ある攻撃者によって、存在しないランダムなソースMACアドレスを数百万個送りつけられる MACアドレスフラッディング攻撃 が発生するとどうなるか？
そう、有限であるCAMテーブルのエントリが枯渇する。
CAMが満杯になると、スイッチは新しい正当なMACアドレスを学習できなくなり、すべてのユニキャストフレームをフラッディング（ハブと同じ動作）し始める。これによりネットワーク帯域が圧迫され、セキュリティ上の深刻なボトルネック（または情報漏洩リスク）を引き起こすのだ。これに対抗するのが、お馴染みの Port Security 機能によるMACアドレス学習数の制限である。
—
5. モダンなインフラエンジニアへのメッセージ
クラウド全盛の時代であっても、私たちが書くWeb APIのレスポンスやコンテナ間の通信は、最終的に物理的なNIC、スイッチのCAM、そしてTCAMの電気信号の海を泳いでユーザーに届いている。
「なぜこのパケットはここでドロップされたのか？」
「なぜこのルーティング変更が即座に反映されないのか？」
その答えの多くは、ソフトウェアの上位レイヤーではなく、ASICのなかで黙々と働き続けるCAMとTCAMという名の「ハードウェアの記憶装置」の制約と挙動の中にある。
プロトコルの美しさと、それを支えるハードウェアの泥臭い物理的制約。その両者を理解してこそ、真の意味で「障害に強く、スケーラブルなインフラ」を設計・運用できるエンジニアになれるのだ。
さあ、今日のデバッグ作業に戻ろう。パケットは待ってくれない。
コメント