[c-nsp] sup720 protection on the 6500/7600

Charles Spurgeon c.spurgeon at mail.utexas.edu
Sat Feb 17 18:05:08 EST 2007


When it comes to "mls rate-limit" I have a tale of woe to relate
concerning BugID CSCec44594. This bugid describes how using the
command "mls rate-limit unicast cef receive <n> <n>" in a Sup720
causes pre-existing ACL logic to be inverted. 

For us, the failures caused by this remarkable feature of mls rate
limiting didn't occur immediately. Some days after applying the mls
rate-limit command above we started having "impossible" ping failures
at varying rates from 100% down to 10-20% to router interfaces on our
border router which occurred due to:

1. reversed ACL functions (ingress became egress) due to mls
rate-limit operations and

2. a separate mls icmp rate limiter getting involved when the weird
packet path caused by 1. ended up punting enough packets to the CPU
through the icmp rate limiter that had been configured at a low level
(100pps if memory serves) to cause varying levels of failure.

As you can imagine this was "challenging" to debug and
understand. Having been burnt on this I now regard the mls rate
limiters with an extremely elevated level of caution.

To help explain this admittedly strange sounding issue, here's an
excerpt from email I was sent at the time (2005):
______________________________
> The issue is the implementation of the rate limiters in the hardware
> engine.  What ends up happening is that for the CEF glean and receive
> CPU rate limiters the Tycho ASIC uses the input VLAN for part of the
> egress lookup and if there are any outbound features on this input vlan
> they are applied to the packet.  So in your case you are seeing packets
> get denied.
______________________________

Apparently this behavior is not going to be fixed since it is an
effect of how the ASICs function (as stated in the bugID).

However, the bugID *does* suggest a way to avoid triggering this
condition: "The symptom can be alleviated by avoiding generating
packets to the RP (ie. this router)."

There, doesn't that make you feel better? :-)

-Charles

Charles E. Spurgeon / UTnet
UT Austin ITS / Networking
c.spurgeon at its.utexas.edu / 512.475.9265


On Sat, Feb 17, 2007 at 09:18:26PM +0000, Phil Mayers wrote:
> Saku Ytti wrote:
> 
> > CoPP is the tool for the job, of course you should also implement iACL
> > and iPolicer in IXP/Transit borders.
> 
> Agreed
> 
> >  'mls ip cef rate-limit' in all possible scenarios I can think of is
> > evil. Consider you're running L3 box, with some routing protocol,
> 
> I agree. BUT, the OP should remember that this:
> 
> mls ip cef rate-limit
> 
> and this:
> 
> mls rate-limit
> 
> ...are different. The latter (set of options) should ALWAYS be set in my 
> opinion. Thankfully the most important ones are on by default.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list