I don't believe it FILLED the pipe. I suspect it made the interface unusable by consuming buffer/processes/io ... Other interfaces on the system were still functional. I did NOT measure the actual through put.
[EMAIL PROTECTED] GCIA http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC kill -13 111/2 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Christopher L. Morrow > Sent: Wednesday, May 05, 2004 5:31 PM > To: Patrick W.Gilmore > Cc: [EMAIL PROTECTED] > Subject: Re: BGP Exploit > > > > On Wed, 5 May 2004, Patrick W.Gilmore wrote: > > > > > On May 5, 2004, at 2:39 PM, Smith, Donald wrote: > > > > > No. The router stays up. The tool I use is very fast. It > floods the > > > GIGE to the point that that interface is basically > unusable but the > > > router itself stays up only the session is torn down. I did > > > preformed these tests in a lab and did > > > not have full bgp routing tables etc ... so your mileage may vary. > > > > That is DAMNED impressive. I've never seen a router which > can take a > > Gigabit of traffic to its CPU and stay up. What kind of router was > > this? You mentioned Juniper and Cisco before, but I know a > cisco will > > fall over long before a gigabit and a Juniper either does or drops > > packets destined for the CPU (but keeps routing). > > recieve-path acl and recieve-path-limits perhaps on a cisco > will allow survival? Though if this is 'bgp' from a valid > peer it seems likely to crunch it either way. > > > > > Perhaps it was rate limiting the # of packets which reached > the CPU, > > and the session stayed up because the "magic" packet was dropped in > > the rate limiting? > > > > That sees likely. >
