nanog mailing list archives
RE: Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot))
From: "Lincoln Dale" <ltd () interlink com au>
Date: Sat, 5 Apr 2008 21:40:52 +1100
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:ltd () cisco com)
Current thread:
- "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Paul Vixie (Apr 04)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Christopher Morrow (Apr 04)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Steven M. Bellovin (Apr 05)
- Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)) Jeroen Massar (Apr 05)
- Re: Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)) Roland Dobbins (Apr 05)
- RE: Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)) Lincoln Dale (Apr 05)
- RE: Flow Based Routing/Switching (Was: "Does TCP Need an Overhaul?" (internetevolution, via slashdot)) michael.dillon (Apr 05)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Kevin Day (Apr 05)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Paul Vixie (Apr 05)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Kevin Day (Apr 05)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) David Andersen (Apr 05)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Sam Stickland (Apr 07)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Paul Vixie (Apr 05)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Hank Nussbacher (Apr 05)
- RE: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Charles N Wyble (Apr 05)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Jorge Amodio (Apr 05)
- Message not available
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Hank Nussbacher (Apr 05)
- Re: "Does TCP Need an Overhaul?" (internetevolution, via slashdot) Christopher Morrow (Apr 04)