[j-nsp] Flow Based Router

[Richard A Steenbergen]

On Wed, Dec 23, 2009 at 05:23:13PM +0100, sthaug at nethelp.no wrote:
> I doubt anybody is planning to make a flow-based version of a T1600 or
> a Cisco CRS-1.
> 
> Personally, I was sad to see the J series become flow based. Yes, I
> know that it can be turned off - but the software bloat is still there
> and so is the opportunity for bugs.

My understanding of the new flow-based J-series software is that they
are reusing some of the netscreen designs, and the flow based routing
allows them to implement some specific security/firewall features. 

The reason they used to make flow based routers in the past is that
doing longest prefix matching is actually a pretty difficult operation
(one of the unintended consequences of CIDR, which solved addressing
inefficiencies but which massively retarded the development of high
speed routers in the process), while doing exact matches was relatively
easy and could be implemented in hardware for cheap. One solution to
this problem was simply to do the longest prefix match once in software,
and then program the result into a hardware flow table so that future
packets on the same flow could be handled entirely in hardware. This
actually worked pretty well under normal traffic conditions, and was a
shortcut to achieving "high performance" routing that otherwise would
have been impossible. 

Unfortunately it also failed spectacularly under any kind of abnormal
traffic conditions, such as Denial of Service, random destination port
scanning, or even use as a "core" box with a large number of flows
passing through it. After quite a few years of people having their
30Mpps box turn into a 300pps box whenever a new worm would come along
and start doing random dest scanning, and a little advancement in ASIC
technology to implement the longest prefix lokups, the industry as a
whole shifted away from flow-based and towards a packet based
prepopulated FIB model. A prepopulated fib consumes more initial 
resources (e.g. where folks used to be able to make a "functional" edge 
device with only 16-32k hardware entries, it now requires 256k+ to 
handle the entire routing table), but it had two main advantages when it 
came to making stable/predictable routers. #1 you could never exhaust a 
hardware flow table by artificially creating a large number of flows 
i.e. DoS/random dest, and #2 you didn't have differing levels of 
performance between the first routing lookup in software and future flow 
lookups in hardware.

These days we've mostly solved the problems of implementing high speed
longest prefix match lookups in hardware, and having enough FIB
resources to hold a full table while doing it. That's not to say that
these aren't major cost factors in the hardware, they most certainly
are, but hopefully the industry has learned its lesson about building
boxes which don't offer consistent performance under all conditions. The
closest thing you would ever want to see to a low-FIB box without
hardware based longest prefix match capabilities today would be a
dedicated MPLS-only core box capable of higher speeds/densities at lower
cost. Outside of a specific application like a security box doing
stateful / flow based stuff, there is absolutely zero reason for anyone
to bring back a flow based router today.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)