For Cisco Hardware dCEF, based on some documents published on Cisco website, at the ingress line card/interface, conceptually it looks up the FIB with dst IP address, and gets a pointer to an adjacency table entry, where L2 rewrite information is stored, e.g. nexthop mac, etc.
But what confuses me is, doesn't the L2 rewrite happen on egress line card/interface? If so, then why this adjacency table is stored on ingress? Or where is the adjacency table look up happening? ingress or egress? If this is on ingress, are the L2 rewrite information carried over from ingress card to egress line card? Wouldn't that be a waste of fabric bandwidth?
Best Answer
Not really, the forward / drop decision, L2 adjacency lookup, decrement TTL, IP Checksum calculation, etc... all happen on the ingress linecard.
Conceptually, you can break the information flow into a control-plane and data plane, even within the router chassis. It seems that most of your confusion revolves around how the control plane works... this is a quick diagram I hacked up to illustrate...
Synchronized IPC is pretty critical to dCEF's operation; if you don't keep messages synchronized between all linecards, you can wind up with prefix inconsistencies.
The mechanics of how the router does this is platform-specific, so I'll reference the platform I know best which is Catalyst 6500 with Supervisor720 / Supervisor2T. The forwarding & rewrite engine on a Catalyst 6500 dCEF linecard is actually a miniature copy of the Supervisor itself; so the whole IP forwarding and switching process executes just like it does as if the packet was centrally forwarded on the supervisor. The ingress dCEF linecard looks up the required information in the CAM / CEF table, and then builds a header which it attaches to the packet.
The egress linecard looks at the header and uses the adjacency information inside it to write the packet onto the wire.
So you can make the entire forwarding decision on ingress.
Yes
I don't think so, but then again I could be biased :-)