07-08-2023 02:37 AM - edited 07-08-2023 02:57 AM
Hi everyone,
Can any one add some value in this diagram in terms of forwarding (MPLS packet and IP packet).
This is how packet get flow right?
07-08-2023 07:45 AM - edited 07-08-2023 08:03 AM
Conceptually, packets (labeled or unlabeled) do not actually flow "through" the FIB/LFIB as might be inferred from the diagram. The packet processing (or forwarding) engine, whether implemented in s/w or NPU, uses the FIB/LFIB to look-up the next-hop, outgoing interface, and outgoing encap (new label, new MAC addr, tunnel encap, VLAN ID, etc). The engine then "switches" the ingress packet to the egress interface queue (real or virtual) over whatever switching mechanism that element utilizes.
In the case of many single-NPU systems, the engine decaps the ingress header, sends the header through a packet processing pipeline (or run-to-completion processor), performs the FIB/LFIB lookup in TCAM or SRAM, builds a new egress header, and then links the packet (with new header) to a VOQ. [I am leaving out QoS processing as it is not in your question]. The "switching" takes place by linking the packet buffer used at ingress to the VOQ, but the packet should not be copied to a new location in memory with a single NPU as that would cut throughput.
I know this all sounds pedantic, but I believe a better way to conceptualize the forwarding would be to show a forwarding engine inline with the packet flow, The engine would have connections to the FIB/LFIB (which are populated by control plane from RIB/LIB), but FIB TCAM hardware would not be inline with the packets (ie, packets are not copied in and out of TCAM).
07-08-2023 08:59 AM
Clarification bit hazy. Is it possible to make more clarity on logical only.? correlate logica
07-08-2023 10:27 AM - edited 07-08-2023 10:29 AM
Hi,@TangoAlfa
Start with your (or @MHM Cisco World or M02@rt37 ) diagram which depicts packets in and out of the FIB/LFIB. Below the FIB/LFIB blocks draw another block labeled something like "Packet Forwarding Engine" or "Packet Processing Engine" (Cisco is not consistent on what it calls these). Move the traffic arrows from the FIB/LFIB blocks to the PFE/PPE instead, but connect the FIB/LFIB blocks to the PFE/PPE to show that it looks up the next-hop info in these information bases. You want to end up showing that packets flow through (ie, are forwarded by) the PFE/PPE, which relies on FIB/LFIB to determine next-hop/egress-interface/egress-encap, but the packets themselves are not sent to the FIB/LFIB.
Also note that LDP (RFC 5036) is not the only way to populate a LIB, as both BGP and IS-IS can distribute unicast labels. You might generalize the LDP-LIB portion of the diagram to allow for label info other than from LDP.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide