> > i wouldn't want to get in an argument with somebody who was smart and savvy
> > enough to invent packet switching during the year i entered kindergarden,
> > but, somebody told me once that keeping information on every flow was *not*
> > "inexpensive."  should somebody tell dr. roberts?
> 
> Isn't the reason that "NetFlow" (or v10 which is the the IETF/Cisco
> named IPFIX) exists the side-effect of having routers doing "flow based
> routing" aka "keeping an entry per IP flow, thus using that entry for
> every next packet to quickly select the outgoing interface instead of
> having to go through all the prefixes" ?

flow-cache based forwarding can work perfectly fine provided:
 - your flow table didn't overflow
 - you didn't need to invalidate large amounts of your table at once (e.g.
next-hop change)

this was the primary reason why Cisco went from 'fast-switch' to 'CEF' which
uses a FIB.

the problem back then was that when you had large amounts of invalidated
flow-cache entries due to a next-hop change, typically that next-hop change was
caused by something in the routing table - and then you had a problem because
you wanted to use all your router CPU to recalculate the next-best paths yet
you couldn't take advantage of any shortcut information, so you were dropping
to a 'slow path' of forwarding.


for a long long time now, Cisco platforms with netflow have primarily had
netflow as an _accounting_ mechanism and generally not as the primary
forwarding path.

some platforms (e.g. cat6k) have retained a flow-cache that CAN be used to
influence forwarding decisions, and that has been the basis for how things like
NAT can be done in hardware (where per-flow state is necessary), but the
primary forwarding mechanism even on that platform has been CEF in hardware
since Supervisor-2 came out.


no comment on the merits of the approach by Larry, anything i'd say would be
through rose-coloured glasses anyway.


cheers,

lincoln.
(work:[EMAIL PROTECTED])

Reply via email to