CEFとは？仕組みとメリットを初心者にもわかりやすく解説します！

CEFとは何か。検索するとCisco Express ForwardingとCommon Event Formatが混在し、どれを読めばよいか迷いがちです。

さらにFIBやAdjacency、ECMP、偏りなど専門語も壁になります。

本記事では、まず混同を解消し、次に仕組みと違いをやさしく図解。最後に設計指針や設定例、確認コマンドまでまとめ、入門から実務まで一気に理解へ導きます。

外資系エンジニア

この記事は以下のような人におすすめ！

CEF（Cisco Express Forwarding）とは何か知りたい人

CEFの具体的な仕組みの詳細を知りたい人
FIBやAdjacencyとCEFの違いが知りたい人

1 CEFとは？
- 1.1 1-1. なぜCEFが開発されたのか：従来方式（プロセススイッチング／ファストスイッチング）の課題とは？
- 1.2 1-2. CEFの基本概念：FIBと隣接テーブル（Adjacency）の役割
2 CEFの仕組み詳細
3 CEFの動作モード：セントラルCEFと分散CEF（dCEF）とは？
- 3.1 3-1. セントラルCEF（中央プロセッサがFIB／Adjacency管理）
- 3.2 3-2. 分散CEF（ラインカードがテーブルを保持し高速転送）
4 CEFと他の転送方式との比較
5 実装時の考慮点とベストプラクティス
6 CEF活用の実例と応用
- 6.1 6-1. 大規模ネットワークでのCEFメリットと導入事例
- 6.2 6-2. CEFとSIEMなどの他システム（Common Event Format）との名称混同への注意点

CEFとは？

「CEFとは、Cisco Express Forwarding の略で、Cisco ルータやスイッチがパケットを高速かつ安定して転送するための方式」を指します。

つまり、経路学習そのもの（ルーティング）は従来どおり行い、転送処理だけを最適化するのが CEF の狙いです。

検索意図としての「CEFとは」はしばしば Common Event Format（ログ形式）とも混同されますが、本記事ではネットワーク転送方式の Cisco Express Forwarding を中心に解説します。

なぜなら、ネットワーク設計・運用の現場で「なぜ速いのか」「どう設定・確認すべきか」という実務的な疑問が最も多いからです。

まず、従来方式との違いを一目で確認しましょう。

観点	プロセススイッチング	ファストスイッチング	CEF（Cisco Express Forwarding）
初回パケット処理	毎パケット CPU でルックアップ	初回のみ CPU、以降はキャッシュ	すべてハードウェア寄りの FIB/Adjacency で即時
仕組み	ルーティングテーブル参照を毎回実行	転送結果をキャッシュ再利用	FIB（転送用）と Adjacency（隣接情報）を常時整備
スループット	低い（CPU 依存）	中〜高（キャッシュ命中次第）	高い（安定して線速に近い）
安定性	混雑に弱い	キャッシュミスで性能揺らぐ	変動が少なく予測しやすい
大規模化	不向き	キャッシュがネック	大規模でもスケール

このように、CEFとは「常に用意された最短経路の地図（FIB）と、次にどの扉をどう開けるかの鍵束（Adjacency）」で迷わず転送する仕組みだと考えると分かりやすいでしょう。

1-1. なぜCEFが開発されたのか：従来方式（プロセススイッチング／ファストスイッチング）の課題とは？

複雑化・高速化するトラフィックに対して、従来の方式には次のような限界がありました。

したがって、「CEFとは何か」を理解するには、まず過去の課題を押さえることが近道です。

1-1-1. プロセススイッチングの限界

毎パケットを CPU で処理
ルータのソフトウェアが都度ルーティングテーブルを参照するため、トラフィックが増えるとすぐに CPU が飽和します。
遅延とドロップの増加
キューが膨らみ、結果として遅延やパケットロスが発生しやすくなります。
大規模化に不向き
ルート数やフロー数が増える現代ネットワークでは現実的ではありません。

1-1-2. ファストスイッチングの限界

キャッシュ依存による性能のブレ
初回パケットは CPU 処理、以降はキャッシュを使う方式です。つまり、キャッシュミスが起きると性能が急落します。
アプリ特性に左右される
短命フロー（小さな通信が多数）ではキャッシュが活きにくく、したがって安定しません。
更新・無効化コスト
ネットワーク変化のたびにキャッシュ再計算が必要で、運用負荷や瞬間的な性能低下を招くことがあります。

1-1-3. だから CEF が必要になった

常時整備された転送テーブル
CEF はルーティング変化をトリガに FIB と Adjacency を自動で再構築。その結果、パケット到着時にはすでに最適な転送情報が揃っています。
ハードウェアの力を活用
ASIC などのハードウェアでルックアップを実行でき、線速に近い処理が期待できます。
大規模ネットワークでの安定運用
キャッシュに依存しないため、トラフィック特性に左右されにくく、予測可能なパフォーマンスを提供します。つまり、「常に速い」を目指す設計思想です。

1-2. CEFの基本概念：FIBと隣接テーブル（Adjacency）の役割

ここからが核心です。CEFとは、簡単に言えば「FIB（Forwarding Information Base）」と「Adjacency（隣接テーブル）」の二本柱で構成されます。

なぜなら、この二つが役割分担することで、最短経路選択と L2 再書き込みを一気通貫で実現するからです。

1-2-1. FIB（Forwarding Information Base）とは

転送専用に最適化された経路表
ルーティングテーブルを「検索しやすい形」にコンパイルしたものが FIB です。
最長一致検索に強い構造
プレフィックスごとに最適経路を持ち、ASIC などでの高速検索に向いた形で保持します。
経路変化を即時反映
OSPF や BGP などの学習変化を受けて、FIB が自動更新されます。その結果、最新の最適経路で転送できます。

# ネットワークエンジニアなら知っておきたいFIB/RIBの基礎知識 – 第1回: ネットワークの縁の下の力持ち – FIB/RIBとは #NW – Qiita

1-2-2. 隣接テーブル（Adjacency）とは

次ホップまでの L2 情報を保持
具体的には ARP/NDP 解決済みの MAC アドレス、出力インターフェース、ヘッダ再書き込み（rewrite）情報などを格納します。
FIB と連携して即転送
FIB が「どこへ送るか」を決め、Adjacency が「どう送るか（L2）」を即時に提供するため、CPU を経由せず処理が進みます。
解決状況の管理
ARP 未解決などの場合には一時的に特別なエントリ（例えば glean）で扱い、解決後に通常エントリへ置き換えられます。

【図解/OSPF】アジャセンシー（隣接関係）確立 | SEの道標

1-2-3. パケット転送の流れ（簡略）

受信：パケットがインターフェースに到着。
FIB 検索：宛先 IP の最長一致検索で「次ホップ（または出力）」を即決定。
Adjacency 参照：対応する再書き込み情報（MAC など）を取り出す。
転送：ヘッダを書き換え、出力インターフェースから送出。

この一連はハードウェアにオフロードされ、したがって一定で高速です。

さらに、ECMP（等コスト複数経路）がある場合は、ハッシュ値に基づくロードバランシングを実施します。

だから、フローごとの経路固定性を保ちつつスループットを引き上げられます。

CEFの仕組み詳細

「CEFとは何か」を一段深く理解するには、内部を支える二つの柱、FIB（Forwarding Information Base）と隣接テーブル（Adjacency）を押さえることが近道です。

つまり、FIBが「どこへ送るか」を即決し、Adjacencyが「どう送るか」を即実行することで、最初のパケットから高速転送を実現します。

2-1. FIB（Forwarding Information Base）とは何か？

2-1-1. FIBが必要とされる理由

従来のルーティングテーブルは人間が読むには適していますが、高速な最長一致検索には向いていません。

そこで「CEFとは、転送専用に最適化した検索用データ構造（FIB）を使う方式」であり、したがって処理はハードウェアにもオフロードしやすく、安定して速いのが特徴です。

2-1-2. ルーティングテーブルとの違い

目的：
- ルーティングテーブル＝経路学習と最適経路の全体像
- FIB＝最短時間で転送先を引き当てるための検索表
更新タイミング：
- ルーティングが変化すると、FIBが即座に再構築されます。だから、経路変更直後でも最初のパケットから迷いません。
検索方法：
- FIBは最長一致検索を効率化する構造（圧縮やトライ系構造などの実装）を採用し、結果として線速に近い検索が可能です。

2-1-3. FIBの主なエントリとECMP

プレフィックスごとに「次ホップ」「出力IF」「参照するAdjacency」を保持
等コスト経路（ECMP）がある場合は、同一宛先に複数の次ホップを並列に管理
その結果、後述のハッシュ分散（ロードバランシング）に即応できます

2-1-4. スケーラビリティと安定性

FIBはキャッシュではありません。常時整備された「確定情報」なので、短命フローが多い環境でも性能がぶれにくい点が強みです。

つまり、「CEFとはキャッシュミスに悩まない設計思想」と言い換えられます。

2-2. 隣接テーブル（Adjacency）の仕組みと役割

2-2-1. Adjacencyが担う具体的な仕事

Adjacencyは、次ホップへ届けるためのレイヤ2情報（再書き込み情報）を保持します。

なぜなら、FIBが「行き先」を決めても、実際に出力するためにはMACやタグ類などの詳細が必要だからです。

保持する代表例：
- 次ホップMAC（ARP/NDP解決済み）
- 出力インターフェース（VLAN/サブインターフェース含む）
- ヘッダ再書き込みテンプレート（L2ヘッダ、場合によりMPLSラベルなど）

2-2-2. 未解決・例外時の挙動

ARP/NDP未解決時：一時的に「glean」等の特殊エントリで制御し、解決後に通常Adjacencyへ置き換え
到達不能やフィルタ要件：ドロップやポリシーに紐づくエントリで例外処理
したがって、解決状況に応じて適切な処理に分岐でき、無駄なCPU介入を抑えます

2-2-3. FIBとAdjacencyの役割分担（要点整理）

項目	FIB	Adjacency
主目的	宛先へ最短で「行き先」を決める	宛先へ実際に「送り出す」ためのL2再書き込み
主な中身	次ホップ、出力IF、Adjacency参照	次ホップMAC、出力IF、再書き込みテンプレート
更新契機	ルーティング変化	ARP/NDP解決、到達不能・例外の状態
性能影響	最長一致検索の高速化	ヘッダ書換の即時化、CPU節約
まとめ	どこへ	どうやって

このように、CEFとはFIBとAdjacencyの協調作業だと理解すると、設定やトラブルシュートの道筋が明確になります。

2-3. パケット転送の流れ：検索から転送までの仕組み

2-3-1. 受信から分類まで

パケット受信（物理/論理IF）
最低限の分類やACL、QoSマーク確認
転送が許可されると、即座にFIB検索へ

2-3-2. FIB最長一致検索で次ホップ決定

宛先IPをキーに最長一致検索
該当エントリに紐づく「出力IF」と「参照すべきAdjacency」を取得
ECMPがあれば複数候補を保持

2-3-3. Adjacency適用とL2再書き込み

対応Adjacencyから、再書き込みテンプレートを取得
送信フレームのL2ヘッダ（送信元/宛先MAC、VLANタグ、必要に応じてラベル等）を構成
したがって、CPUを経由せずに最短経路で出力が可能

2-3-4. ロードバランシング（ECMP）のハッシュ計算

フロー特性（送受信IP、ポート、プロトコルなど）を元にハッシュを計算
その結果、同一フローは同一経路に固定され、順序性を維持
偏り（ポラリゼーション）対策として、装置ごとにシードを変える方式などが使われます

2-3-5. 全体像の一枚絵（簡略フロー）

受信IF
  ↓
前処理（ACL/QoSなど）
  ↓
FIB最長一致検索 ──→ 次ホップ/出力IF 確定
  ↓                       ↓
Adjacency参照  ───→  再書き込み情報取得
  ↓
L2ヘッダ再構成（必要に応じラベル/タグ付与）
  ↓
出力IFから送出（ECMPならハッシュ分散後）

CEFの動作モード：セントラルCEFと分散CEF（dCEF）とは？

まず押さえたいのは、「CEFとは、FIBとAdjacencyを常時整備して最初のパケットから高速転送する方式」であり、その実装形態としてセントラルCEFと**分散CEF（dCEF）**があるという点です。

つまり、どこにFIB/Adjacencyを保持して誰が転送処理を担うのかが、両者の最大の違いです。

したがって、装置の規模やトラフィックの性質に応じて、適切なモードを選ぶことがネットワーク性能と運用性を左右します。

3-1. セントラルCEF（中央プロセッサがFIB／Adjacency管理）

3-1-1. 仕組みの概要

セントラルCEFは、装置の中央プロセッサ（スーパーバイザ／メインCPU）がFIB/Adjacencyを一元管理し、必要に応じてラインカードへ参照・指示を行う方式です。言い換えると、制御と転送の“頭脳”が中央に集約されます。

3-1-2. メリット（なぜ選ばれるのか）

設計がシンプル：テーブルが中央に集まり、可視化・把握が容易。
トラブルシュートが直感的：確認ポイントが少なく、原因切り分けがしやすい。
中小規模に適合：ポート数やスループット要件が中程度なら十分に高性能。

3-1-3. デメリット（注意すべきポイント）

スケールの壁：すべての更新・同期負荷が中央に集中しやすい。
高スループットでの制約：大規模ECMPや多量のフローでCPU/バスがボトルネック化する恐れ。
冗長性設計が鍵：中央障害が影響範囲を広げる可能性があるため、冗長構成・フェイルオーバー設計が重要。

3-1-4. 向いているユースケース

集約SW/ルータでの中規模ネットワーク
トラフィックの変動が緩やかで、可視化・運用の簡潔さを重視
将来的にdCEFへ移行する前段階の設計・検証環境

3-2. 分散CEF（ラインカードがテーブルを保持し高速転送）

3-2-1. 仕組みの概要

分散CEF（dCEF）は、各ラインカードやASICがFIB/Adjacencyをローカル保持し、パケット転送をカード上で完結させる方式です。

つまり、パケットは入ってきた場所で即時に検索・再書き込みが行われ、中央の介在を最小化できます。

3-2-2. 同期の考え方（FIB/Adjacency配布）

コントロールプレーンで学習→配布：OSPF/BGP等の経路変化を中央が受け、最適化済みのFIBを各カードへ配布。
Adjacencyの局所解決：ARP/NDPなどのL2情報は、各カードが自インターフェースに近い場所で解決・保持。
その結果、更新は広く薄く分散され、転送経路もローカルで閉じるため、装置内の帯域やCPU負荷が平準化されます。

3-2-3. メリット（大規模・高性能に強い理由）

線速処理に近い性能：入ったカードで即検索・転送するため、背面バス往復の無駄が減る。
高いスケーラビリティ：カードを増やすほど処理能力・テーブル容量が拡張。
大規模ECMPへの適性：多数プレフィックス・多数フローでも性能の“揺れ”が小さい。
結果として安定運用：大規模トラフィックでもCPU/バス集中が起きにくい。

3-2-4. デメリット（設計上の落とし穴）

構成・同期の複雑化：カード間・世代間でのテーブル整合性や、リビルド時の設計配慮が必要。
メモリ要件の増加：各カードがFIB/Adjacencyを持つため、総メモリ消費は増えやすい。
トラブルシュート範囲が拡大：問題発生時は“どのカードのどのテーブル”かを素早く特定する仕組みが重要。

3-2-5. ロードバランシング（ECMP/ポートチャネル）との相性

フローハッシュをカード単位で計算し、同一フローは同一路に固定。
したがって、順序性を維持しつつ高スループットを実現。
さらに、ハッシュシードの工夫により、**偏り（ポラリゼーション）**を低減可能。

セントラルCEFと分散CEFの比較（要点早見表）

観点	セントラルCEF	分散CEF（dCEF）
FIB/Adjacencyの所在	中央プロセッサに集約	各ラインカードに分散保持
転送処理	中央関与が相対的に大	各カードで完結、線速志向
スケール	中小規模向け	大規模・高密度向け
運用の分かりやすさ	高い（シンプル）	中（構成・同期が複雑）
影響範囲	中央障害で広がりやすい	カード障害は局所化しやすい
メモリ/コスト感	比較的抑えやすい	増えやすい（カード側に搭載）
ユースケース	集約/配下向け、検証環境	コア/大規模データセンタ

CEFと他の転送方式との比較

「CEFとは何か」を実務で使える知識に落とし込むには、従来方式との違いと優位点をおさえることが近道です。

つまり、プロセススイッチングやファストスイッチングが抱える構造的な限界を理解すると、なぜCEFが“最初のパケットから速い”のかがすっきり見えてきます。

4-1. プロセススイッチング、ファストスイッチングとの違い

4-1-1. 方式別の基本イメージ

プロセススイッチング：毎パケットをCPUで処理。ルーティングテーブルをその都度参照。
ファストスイッチング：初回はCPU、以降は結果をキャッシュで転送。
CEF（Cisco Express Forwarding）：常時整備されたFIBとAdjacencyで、最初のパケットからハードウェア寄りに即転送。

4-1-2. 一覧で理解（最初のパケット、安定性、スケール）

比較軸	プロセススイッチング	ファストスイッチング	CEF（Cisco Express Forwarding）
最初のパケット	毎回CPU処理	初回のみCPU	いきなりFIB/Adjacencyで線速志向
データ構造	ルーティング表を逐次参照	転送結果をキャッシュ	FIB（検索用）とAdjacency（再書き込み）を常時整備
性能の安定性	低い（混雑で劣化）	中（キャッシュミスで揺れる）	高い（キャッシュに非依存）
CPU依存度	高い	中	低い（ASIC活用）
スケーラビリティ	低い	中	高い（多数プレフィックス/フローに強い）
収束後の挙動	CPUの余力次第	キャッシュ作り直しに左右	FIB/Adjacency即更新で安定

4-1-3. だから何が違うのか（要点）

CEFとは「最適化済みの転送表を“常に”持っている」方式。
キャッシュ前提ではないため、短命フロー多発時やフロー分散が激しい環境でも性能がブレにくい。
その結果、トラフィック状況に依存せず予測可能なスループットを得やすいのが最大の差です。

4-2. CEFの優位点：速度、スケーラビリティ、CPU負荷の低減など

4-2-1. 速度（最初の1パケット目から速い）

FIBとAdjacencyが常設のため、到着直後に最長一致検索とL2再書き込みが完了。
つまり、ウォームアップ不要で初速から線速志向の挙動を示します。

4-2-2. スケーラビリティ（大規模環境でも安定）

多数のプレフィックスやECMPにも対応しやすい設計。
キャッシュ無効化や再学習の“揺れ”が少なく、したがって大規模でも安定した処理能力を維持しやすい。

4-2-3. CPU負荷の低減（オフロード前提の設計）

ルックアップはハードウェア寄りにオフロード。
その結果、CPUは制御プレーンに集中でき、全体の健全性が高まります。

4-2-4. 予測可能性とトラブル抑止

キャッシュヒット率に左右されないため、遅延やジッタが読める。
さらに、障害時の挙動もFIB/Adjacency再構築で収束しやすく、復旧後の性能リバウンドが小さい傾向。

4-2-5. ECMP・ロードバランシングとの相性

ハッシュベースでフローを分散し、同一フローは同一路へ固定。
だから、順序性を保ちつつ帯域を有効活用できます。

4-3. 実運用上のパフォーマンスへの影響

4-3-1. よくあるボトルネックとCEFの効き方

短命フローの多発（Web/API、マイクロサービス）
ファストスイッチングではキャッシュが生きない場面が多い一方、CEFとはキャッシュに依存せず安定。
大量ECMP/広域プレフィックス（ISP/データセンタコア）
FIB最長一致とAdjacency参照で、大規模でも一定性能を発揮。
コントロールプレーン保護
データプレーンが自律的に高速処理するため、CPU過負荷の波及を軽減。

4-3-2. ポラリゼーション（偏り）と対策の考え方

現象：特定のハッシュ値にフローが集中してリンクが偏ること。
対策：ハッシュシードの調整、分散アルゴリズムの変更、エントロピ拡張（L4ポート含む）など。
ポイント：偏りは“CEFの欠点”ではなく設計・パラメータのチューニング課題。適切に調整すれば高い分散効果が得られます。

4-3-3. 機能連携時の注意（ACL/QoS/NAT/MPLSなど）

ACL/QoS：ハードウェアでの同時適用を想定し、順序とヒット率を設計。
NAT：フローベースの変換がハッシュに影響しうるため、エントロピ確保を考慮。
MPLS/VXLAN：ラベル/ヘッダの再書き込みもAdjacencyで処理。仕様・実装差に注意。

4-3-4. 運用のベストプラクティス（要点）

観測：インターフェース利用率、ドロップ、CPU、FIB/Adjacency統計を定期チェック。
分散：ECMPやポートチャネルのハッシュ項目を業務トラフィックに合わせて最適化。
設計：将来のプレフィックス増や機能追加を見込み、FIB/Adjacency容量とラインカード性能に余裕を持たせる。

実装時の考慮点とベストプラクティス

「CEFとは何か」を理解したら、次はどう設計し、どう運用で活かすかが肝心です。

ここではロードバランシング方式の選択、偏り（polarization）対策、そして現場で使えるコマンド群までを、実務の流れに沿って整理します。

5-1. ロードバランシング方式（Per-destination / Per-packet）と設定例

5-1-1. 二つの方式の違いと選び方

Per-destination（推奨）
フロー（多くは送信元/宛先IP、必要に応じL4ポートを含む）単位で経路を固定します。
つまり、同一フローのパケット順序が崩れにくいため、TCPやリアルタイム系でも扱いやすいのが利点です。
Per-packet（用途限定）
パケットごとに経路を決め直します。リンク使用率は平準化しやすい一方、パケット順序の乱れが起こりやすく、アプリによっては性能が悪化します。
したがって、特殊要件や一時的な検証以外では採用を慎重に。

5-1-2. 方式別の比較（早見表）

項目	Per-destination	Per-packet
分散粒度	フロー単位	パケット単位
順序性	保たれやすい	乱れやすい
帯域平準化	中程度	高い
使い所	常用・標準	例外・検証・一部ユースケース
SEO観点の要約	CEFとはフローを固定して安定化	CEFとは平準化を優先する特殊手段

5-1-3. 代表的な設定例（IOS系のイメージ）

Per-destination は多くの装置でデフォルトです。加えて**ハッシュの改良（後述の Universal）**や、L4ポートを含む分散設定（機種依存）を検討します。

! CEFの有効化（多くは既定で有効）
configure terminal
 ip cef
 ipv6 cef
!
! ハッシュのアルゴリズムをUniversalに（偏り対策）
 ip cef load-sharing algorithm universal
end

Per-packet を使う場合の一例（プラットフォームによってコマンドは異なります。実機のドキュメントを必ず確認してください）。

configure terminal
 interface GigabitEthernet0/0
  ip load-sharing per-packet
end

EtherChannel/ポートチャネル側での分散指定も重要です（L2/L3の両面で整合させると効果的）。

! 機種により表記が異なる例
configure terminal
 port-channel load-balance src-dst-ip
! 可能なら src-dst-ip-port など L4を含める
end

5-1-4. ECMPの併用とルート設定の勘所

ECMP（等コスト複数経路）を有効にすると、FIB上に複数の次ホップが並び、CEFとはその中でハッシュ分散します。

! 等コストのスタティックを2本
ip route 203.0.113.0 255.255.255.0 192.0.2.1
ip route 203.0.113.0 255.255.255.0 198.51.100.1
!
! ルーティングプロトコルでも maximum-paths でECMP数を調整可能（OSPF/BGP等）

5-2. CEFの偏り（polarization）問題とは？対策アルゴリズム（Universalなど）

5-2-1. 偏り（polarization）とは

複数のルータが同じハッシュ特性でロードバランシングすると、ネットワーク全体で一部リンクにフローが集中する現象が起きます。

つまり、装置が違っても同じ結果に“収束”してしまい、リンクの有効活用ができない状態が偏りです。

5-2-2. なぜ起きるのか（根本原因）

ルータ間で同一のハッシュアルゴリズム/シードを使う
ハッシュキーに**十分なエントロピ（ばらつき）**がない（L4ポートを含まない等）
トラフィック特性が宛先集中など偏っている

5-2-3. 主な対策（実務で効く順に）

Universalアルゴリズムの採用
ルータごとに異なるシードを使うことで、装置間の分散結果を“ずらし”、ネットワーク全体の平準化を図れます。
そのため、多段のECMPを通過しても同じリンクにばかり当たる現象を緩和できます。
ハッシュキーの拡張（可能ならL4ポートを含める）
src/dst IP だけでなく、src/dst ポートやプロトコル番号をキーに含め、エントロピを増やします。
トポロジ/設計面の工夫
経路集約の仕方、リンク数のバランス、チャネル化の設計を見直し、分散が効きやすい構造にします。

5-2-4. 参考設定（Universal の指定）

configure terminal
 ip cef load-sharing algorithm universal
! 一部プラットフォームでは L4ポートをキーに含むロードバランス設定が別途存在
! 例: port-channel load-balance src-dst-ip-port（機種依存）
end

5-3. 設定・確認コマンド、トラブルシューティングのヒント

5-3-1. 動作確認の基本コマンド

FIBの中身を見る（宛先別）
show ip cef
show ip cef 203.0.113.0/24
実際にどのパスを選ぶか（src/dst 指定）
show ip cef exact-route 10.1.1.10 203.0.113.10
隣接テーブルの状態
show adjacency
show adjacency detail
ルーティングの前提確認
show ip route 203.0.113.0

5-3-2. ロードバランスの効き具合を可視化

ハッシュの結果を複数パターンでチェック
送信元アドレスを変えながら show ip cef exact-route を繰り返し、
次ホップが均等に選ばれるかを観測します。
実トラフィックでの分散
インターフェースごとの出力バイト/ppsを比較し、リンク使用率の偏りを評価します。

5-3-3. 典型的な症状と切り分けフロー

一部リンクだけ常に高負荷
まず Universal の有無を確認 → ハッシュキーの見直し（L4含有） → それでも偏るならトポロジ/経路集約を再設計。
パケット順序の乱れでTCP性能が悪化
Per-packet の混在がないか確認 → 可能なら Per-destination へ統一。
ARP/NDP解決待ちで瞬断
show adjacency detail で incomplete / glean を確認 → ARP/NDPのリトライやタイマー/キャッシュの最適化を検討。

5-3-4. 変更の際のチェックリスト

影響範囲：変更は単装置かネットワーク全体か
順序性：リアルタイム／TCP重視なら Per-destination を堅持
エントロピ：L4ポートを含められるか、アプリ特性に合うか
観測基盤：インターフェース統計、フロー可視化、遅延/ジッタの監視が整っているか

CEF活用の実例と応用

まず前提として、「CEFとは Cisco Express Forwarding の略で、FIB と Adjacency を常時整備して最初のパケットから高速転送する仕組み」です。

以下では、大規模ネットワークでの実例と、同じ略称の Common Event Format（ログ形式）との名称混同に注意しながら、現場で役立つポイントを整理します。

6-1. 大規模ネットワークでのCEFメリットと導入事例

6-1-1. ISP／キャリアコアの事例

背景：数十万以上のプレフィックス、広域で多段ECMP、ピーク時のトラフィックが急増。
CEF導入の効果：
- ルックアップが常時FIBで完結し、キャッシュミス由来の性能低下が解消。
- dCEF（分散CEF）で各ラインカードが転送を完結、背面バス往復を抑制。
- その結果、ピークトラフィックでも遅延の揺れが小さく、設備計画が立てやすい。
設計メモ：ECMPの最大経路数、FIB/Adjacency容量、ハッシュアルゴリズム（Universal）を事前評価。

6-1-2. データセンター（リーフ・スパイン）の事例

背景：イースト–ウエスト通信が主体、短命フローが多く、マイクロバーストが発生しやすい。
CEF導入の効果：
- キャッシュに依存しないため短命フローでも初速から安定。
- L3 ECMP とポートチャネルのハッシュ設計を合わせ込み、帯域を広く薄く活用。
設計メモ：ハッシュキーにL4ポートを含める、リーフ/スパインでシードを変える、フロー可視化で偏りを継続監視。

6-1-3. 企業キャンパス／SD-WANエッジの事例

背景：拠点数が多く、アプリが多様化。QoSやセキュリティ機能との同時適用が必要。
CEF導入の効果：
- データプレーンがハードウェア寄りに処理され、CPUは制御プレーンや付加機能に専念。
- したがって、ポリシー適用時のスループット低下を抑制しやすい。
設計メモ：ACL/QoSの順序、NATやトンネル（MPLS/VXLAN）の再書換をAdjacencyで処理できるかを装置仕様で確認。

6-1-4. 課題と効果の早見表

典型課題	CEF適用での効果	追加で注意すべき点
キャッシュミスによる性能揺らぎ	FIB/Adjacency常設で初速から安定	収束時のFIB再構築時間と監視
多段ECMPでの偏り	Universalアルゴリズムで装置間分散をずらす	ハッシュキー拡張（L4含有）
高トラフィック時のCPU飽和	ルックアップをハードウェアにオフロード	例外パス（ポリシー/例外転送）の比率管理
大規模化に伴う可視性低下	`show ip cef` 等で経路ごとの実選択を可視化	フロー可視化基盤と組み合わせる

6-2. CEFとSIEMなどの他システム（Common Event Format）との名称混同への注意点

同じ「CEF」という略称が、Cisco Express Forwarding と Common Event Format（ArcSight由来のログ形式）で使われます。

検索や社内文書で混乱が起きやすいため、文脈を明確にする工夫が重要です。

6-2-1. 用語の違い（まずは定義を固定）

項目	CEF（Cisco Express Forwarding）	CEF（Common Event Format）
分野	ネットワーク転送方式	ログ記録・SIEM連携のイベント形式
役割	FIB/Adjacencyで高速転送を実現	規定のヘッダ・拡張フィールドでログを標準化
主な対象	ルータ／スイッチのデータプレーン	セキュリティ製品、アプリ、SIEM
よくある文脈	ECMP、ハッシュ、dCEF、FIB	syslog、SIEM、パース、フィールドマッピング

6-2-2. 名称混同を防ぐライティング規約（実務で効く）

初出で展開形を併記：
例）「CEF（Cisco Express Forwarding）」／「CEF（Common Event Format）」
括弧で分野を固定：
例）「CEF（転送）」と「CEF（ログ形式）」、または「CEF（Cisco）」「CEF（Log）」
文書先頭に断り書き：
例）本記事での「CEF」とは Cisco Express Forwarding を指します。
検索導線の最適化（SEO）：
タイトルや見出しで「CEFとは（Cisco Express Forwarding）」のように明示し、別記事として「CEFとは（Common Event Format）」を内部リンクで用意。

6-2-3. 実務オペレーションでの混同対策

チケット／手順書のテンプレート化：フィールドに「対象CEF」の選択肢（転送／ログ）を設ける。
監視/アラートの命名規則：
例）NET-CEF-Adjacency-Incomplete（転送）／LOG-CEF-Parse-Error（ログ）
教育とレビュー：用語集を作り、レビュー時に略語の文脈チェックをルール化。

6-2-4. 併記のサンプル文（流用可）

ネットワーク記事の冒頭：
「本記事で扱うCEFとは Cisco Express Forwardingのことです。ログ形式の**CEF（Common Event Format）**とは別概念です。」
セキュリティ記事の冒頭：
「本記事のCEFとは Common Event Formatです。ネットワークの**CEF（Cisco Express Forwarding）**とは異なります。」