[70283] in North American Network Operators' Group
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.