Re: route metric
From: Lars Erik Gullerud (lerik_at_nolink.net)
Date: 06/04/05
- Previous message: Julian Elischer: "Re: xxconfig for if_bridge"
- In reply to: Charlie Schluting: "Re: route metric"
- Next in thread: Hanspeter Roth: "Re: route metric"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 4 Jun 2005 00:16:01 +0200 (CEST) To: Charlie Schluting <schluting@gmail.com>
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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
- Previous message: Julian Elischer: "Re: xxconfig for if_bridge"
- In reply to: Charlie Schluting: "Re: route metric"
- Next in thread: Hanspeter Roth: "Re: route metric"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
