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. Donald.Smith@qwest.com 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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Christopher L. Morrow Sent: Wednesday, May 05, 2004 5:31 PM To: Patrick W.Gilmore Cc: nanog@merit.edu 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.