> > 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])
