route metric

[Lars Erik Gullerud]

On Fri, 3 Jun 2005, Charlie Schluting wrote:

> Reason #2 is latency. Vendor C put a lot of time and money into
> features like CEF that take advantage of hardware packet forwarding. A
> purely software-based device simply can't keep up with large flows,
> and definitely introduces latency--especially when filtering.

Just to set things straight, CEF != hardware packet forwarding. CEF is a 
forwarding/FIB-lookup algorithm that speeds up the packet forwarding by 
using a process to generate the complete FIB in a 256-way trie structure 
in memory from the routes in the RIB. This means the router can forward 
the packet a lot faster directly in the interrupt context when the packet 
is received on the ingress interface, as the trie lookup is a lot more 
efficient & requires fewer steps than older methods like building a 
route-cache based on recent lookups (usually stored in a radix tree).

Case in point, the Cisco 7200, still one of the most widely deployed 
access/aggregation routers out there (especialy among small/medium-sized 
ISPs), is a pure CPU-based central forwarding architecture based on MIPS 
CPUs and PCI buses, which uses CEF central forwarding. Even many early 
12000 GSR linecards merely distributed this function down to individual 
CPUs placed on the linecards (dCEF), they did not have hardware forwarding 
using ASICs/FPGAs.

Yes, newer router models from all major vendors usually rely on 
ASIC-assisted forwarding, and increasingly more dataplane/controlplane 
separation but this has nothing to do with CEF as such.

BTW, "large flows" are actually a lot easier to handle in CPU-based 
forwarding systems, as the limitation then usually lies in the 
available bus bandwidth. It's high packet rates that will kill these 
architectures quickly, due to the number of interrupts that need to be 
serviced and the number of individual FIB lookups this results in (even 
smaller routers handle large amounts of bandwidth if fed with large 
packet sizes and continuous flows).

/leg