Ping flooding (fwd)

Sean Doran smd at
Tue Jul 9 23:43:28 UTC 1996

| 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.

conf t
flow-export <ip-address>

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.


More information about the NANOG mailing list