Ping flooding (fwd)

Daniel W. McRobb dwm at
Tue Jul 9 21:57:12 UTC 1996

> On Jul 9, 14:21, Curtis Villamizar <curtis at> wrote:
> > The NSS routers allow us to do statistical sampling continuously and
> > the occurance of a source address at an entry point where it does not
> > usually enter can be detected and has in the past been used to
> > followup these sort of attacks after the fact.  Other routers are not
> > capable of doing this but if the offense is repeated, successive
> > monitoring can be set up until the source is isolated.
> > 
> > We have requested the same sort of statistical sampling from Cisco and
> > Bay (and BNR/NSC).  It is a long ways back on the development schedule
> Maybe I'm missing something, but flow switching stats from Ciscos
> should do exactly this:
> SrcIf    SrcIPaddress    DstIf    DstIPaddress    Pr DstP SrcP Pkts B/Pk Active
> Se1/0   Se1/6    11 0035 0035    2   69    0.0
> Et0/2   Se1/1   06 0050 0FA3    2   40    0.0
> Se1/5    Se1/0   11 0035 0035    2   69    0.0
> Se1/1    Et0/1    06 0413 0050    4   44    9.6
> Se1/5   Se1/7   06 0407 0050  124   40  207.6
> Se1/7   Se1/6   06 0050 0405  648  550  673.4
> Se1/5   Se1/0  06 0430 0050    5  164    6.2
> etc, etc.  Dump, then grep.

The sampling Curtis mentioned on the NSS routers is a bit different.
For one, it doesn't really impact forwarding performance (and hopefully,
if/when implemented on the Bay, will not impact forwarding performance).
Secondly, there's a lot more information available if you need it (packet
headers or even payload).

But what we're specifically looking for in terms of continuous sampling
(such as that we do on the NSS routers) is a net matrix... if you
changed the Cisco flow switching stuff to use network numbers (and
mask), you'd have something very much like what we're looking for in
terms of continuous sampling.  From there we build AS matrices, etc.
The other thing about the flow-switching data that's different than the
NSS (and probably what we'll get from Bay) is that there aren't really
any nice ways of retrieving/storing the data automatically.

As Curtis pointed out, the data is mostly used for capacity planning and
other network architecture issues.  I have not receieved a request to
track down a cracker with this type of data in a very long time.  Maybe
I've just been lucky.  :-)


More information about the NANOG mailing list