I have always been under the impression that Cisco flow switching and
high performance were mutually exclusive if there were too many active
flows as is the case for the major US ISPs at least.
Not quite. The flow switching path was tuned manually by
Darren Kerr, who is an impressive bit-twiddler. He spent
some time watching how his path behaved in a huge network (mine)
and in a big network (Dorian's) and adjusted it accordingly.
The current path appears -- to me, qualitatively -- to consume
less CPU per packet per second in 7500s than the other released
switching methods. Yes, I was seriously surprised too, however
People That Know with three letter logins weren't.
There are some memory concerns and some concerns about mixing
optimum switching and flow switching in a busy box with
recent code, however these are bugs that don't affect normal
Another difference is with the flow switching, you need to catch them
in the act. With the sampling and collection, you can call hours
later (days or weeks actually, years if you count going to tape) and
still determine the candidate entry points for the traffic. I don't
think there is a practical way to get the same sort of historic
archive from the flow switching stats.
and have a client do whatever you want with the stream of UDP
datagrams that will be sent to you.
The dkerr stuff is neat. I'm looking forward to the completion
of the other work in progress by the folks who've inherited it,
since that has considerable neatness potential too.