[c-nsp] SUP720 - 12.2(18)SXF17

[Marcus.Gerdon]

Besides limiting TTL-1's I'm currently completely dropping (limit 0) acl-drops and rpf-failures. Everything that's being dropped by an rpf 'source any' of course doesn't need a reply, as well as any anti-spoofing/anto-bogon-acl doesn't make sense of a reply sent.

Before reconfiguring a bunch of rate-limiters check for the grouping to be sure not to limit something unintentionally at a rate too low.

Btw, being at mls commands: 'mls cef error action' is a nice one defaulting to 'freeze' (default checked last with SXF10). I'd have to dig for the rather old description about the command but roughly this means freezing updates to the forwarding tables in case of a detected failure. I prefer running 'recover' here - better to rebuilt tables than being stuck with an old table version :-).


regards,

Marcus
 

> -----Ursprüngliche Nachricht-----
> Von: Jared Mauch [mailto:jared at puck.nether.net] 
> Gesendet: Freitag, 9. Oktober 2009 15:16
> An: Drew Weaver
> Cc: Marcus.Gerdon; Bob Snyder; cisco-nsp at puck.nether.net
> Betreff: Re: [c-nsp] SUP720 - 12.2(18)SXF17
> 
> I think it's important to note that there are similar limiters in  
> other devices, eg: Juniper m20/m40 that we've encountered over the  
> years.
> 
> This has caused customer confusion as they hit these, even in 
> a fully  
> distributed linecard environment.  The reality is unless it's 
> done in  
> a low-level ASIC, it can easily turn into a security vulnerability.
> 
> Drop 5 gigs of ttl=1 traffic at a device and it will fall 
> over unless  
> there is some protection.  It may not even need to be as high as 5g.
> 
> There are a lot of rate-limiters available, check out 'show mls rate- 
> limit' on your Earl7 (76k, ie: (65|76)00) based device. Set them low  
> to avoid problems.  I find 100/10 works well.
> 
> 	- Jared
> 
> On Oct 9, 2009, at 9:01 AM, Drew Weaver wrote:
> 
> > 	I assume you were being sarcastic when you said: " But 
> traceroute's  
> > one of the killer apps for Sup720's regardless if used in 6500 or  
> > 7600." as we have found out that whenever the BGP Scanner process  
> > goes wild it totally botches trace routes. Apparently this 
> is not an  
> > issue on the GSR because the line cards originate the ICMP  
> > unreachables but on the 6500/7600 platform the unreachables come  
> > from the RP (or so I'm told). Has anyone found a way to make any  
> > headway on cleaning up the ugly traceroute effect of BGP 
> Scanner? I  
> > obviously realize that traceroutes are all but worthless as far as  
> > diagnostics go, but it's a "presentation" thing.
> >
> > thanks,
> > -Drew
> 
>