Cisco Hardware dCEFの隣接テーブルはどこに保存されますか？

シスコのハードウェアdCEFの場合、シスコのWebサイトで公開されている一部のドキュメントに基づいて、入力ラインカード/インターフェイスで、概念的にはdst IPアドレスでFIBを検索し、L2書き換え情報が格納されている隣接テーブルエントリへのポインタを取得します。例：nexthop macなど

しかし、私を混乱させるのは、L2書き換えが出力ラインカード/インターフェイスで発生しないのですか？もしそうなら、なぜこの隣接テーブルが入力時に保存されるのですか？または、隣接テーブルルックアップはどこで発生していますか？イングレスまたはイーグレス？これが入力である場合、L2リライト情報は入力カードから出力ラインカードに引き継がれますか？それはファブリック帯域幅の無駄ではないでしょうか？

しかし、私を混乱させるのは、L2書き換えが出力ラインカード/インターフェイスで発生しないのですか？

実際には、転送/ドロップの決定、L2隣接ルックアップ、デクリメントTTL、IPチェックサム計算などはすべて、入力ラインカードで行われます。

概念的には、ルータシャーシ内であっても、情報フローをコントロールプレーンとデータプレーンに分割できます。あなたの混乱のほとんどは、コントロールプレーンがどのように機能するかを中心に展開しているようです...

• ルートプロセッサは、レイヤー2の隣接情報（イーサネット、ppp、sonetなど...）とすべての優先ルートからCEFテーブルを構築します
• CEFと隣接テーブルの情報全体がIPCメッセージにパックされ、ルートプロセッサとすべてのラインカード間で送信されます。個々のCEFエントリは、IPCメッセージ内でXDRとしてレンダリングされます。XDRは、CEFエントリをIPCメッセージに書き込むためのシスコ固有の方法にすぎません。
• 個々のラインカードは、IPCメッセージからXDRをアンパックし、ラインカード上のルートプロセッサのCEFおよび隣接テーブルの正確なコピーを作成します（本来あるべきものです）。
• ラインカードがCEFおよび隣接テーブルの修正を完了すると、プラットフォーム固有のプロセスがラインカード上で実行され、プラットフォームのハードウェアがラインカード自体でパケットを転送および再書き込みするために必要なデータ構造を計算します。

同期IPCは、dCEFの運用にとって非常に重要です。すべてのラインカード間でメッセージの同期を維持しないと、プレフィックスの不整合が発生する可能性があります。

ルータがこれを行う方法のメカニズムはプラットフォーム固有なので、Supervisor720 / Supervisor2Tを搭載したCatalyst 6500が最もよく知っているプラ​​ットフォームを参照します。Catalyst 6500 dCEFラインカードの転送および書き換えエンジンは、実際にはスーパーバイザ自体のミニチュアコピーです。したがって、IP転送およびスイッチングプロセス全体は、パケットがスーパーバイザで中央に転送されたかのように実行されます。入力dCEFラインカードは、CAM / CEFテーブルで必要な情報を検索し、パケットに添付するヘッダーを作成します。

出力ラインカードはヘッダーを調べ、その内部の隣接情報を使用してパケットをワイヤに書き込みます。

なぜこの隣接テーブルが入力時に保存されるのですか？

したがって、入力時に転送全体を決定できます。

これが入力である場合、L2リライト情報は入力カードから出力ラインカードに引き継がれますか？

はい

それはファブリック帯域幅の浪費ではないでしょうか？

私はそうは思いませんが、それでも私は偏見があるかもしれません:-)

分散型シスコエクスプレスフォワーディングが有効な場合、VIPラインカードやCisco 12000シリーズインターネットルータラインカードなどのラインカードは、FIBと隣接関係テーブルの同一のコピーを維持します。ラインカードは、ポートアダプタ間のエクスプレスフォワーディングを実行するため、RPがスイッチング操作に関与する必要がなくなります。分散型シスコエクスプレスフォワーディングは、プロセス間通信（IPC）メカニズムを使用して、RPおよびラインカード上のFIBテーブルと隣接テーブルの同期を保証します。- シスコ

RP（さまざまなルーティングプロトコルプロセスを実行）はFIBを構築し、それをすべてのラインカードに公開します。あります1つの FIBは、それはすべてのラインカード上に複製されます。（はい、時々彼らは同期しなくなります。）