From: Lincoln Dale (no email)
Date: Sat Apr 05 2008 - 06:40:52 EDT
> > 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:)
|
|
|