[70283] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: BGP Exploit

daemon@ATHENA.MIT.EDU (Christopher L. Morrow)
Thu May 6 18:53:34 2004

Date: Thu, 06 May 2004 22:52:41 +0000 (GMT)
From: "Christopher L. Morrow" <christopher.morrow@mci.com>
In-reply-to: <8E6001D7-9F4D-11D8-91A9-000A9578BB58@ianai.net>
To: "Patrick W.Gilmore" <patrick@ianai.net>
Cc: nanog@merit.edu
Errors-To: owner-nanog-outgoing@merit.edu



On Thu, 6 May 2004, Patrick W.Gilmore wrote:
> >> 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.
>
> Does this mean you think a cisco would survive a gigabit of traffic
> from a "valid" peer directed at the CPU?  I admit I have not tested

If you employed the recieve-path acls and limits sure... the linecard can
take a gig of traffic, right? :) The neighbor might not be happy since you
would likely rate-limit down peer traffic to some 'normal' level and thus
choke off the real peer and the session would drop in the end anyway. So,
same end effect, different method.

> this, but past experience with similar things would imply _any_ router
> cisco makes would fall over in such a situation - at best just wedging
> and not doing anything (pass packets, SMNP, SSH, etc.), and perhaps
> rebooting, depending upon IOS / model.
>

without the recieve-path stuff it surely will pain the router.

>
> >> 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.
>
> Agreed.  Which makes the test ... not 100% valid.
>

correct.

home help back first fref pref prev next nref lref last post