| 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 processing. | 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. conf t flow-export <ip-address> ^Z 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. Sean.