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

[Saku Ytti]

On (2007-02-17 18:27 +0100), vince anton wrote:

Hey,

> Looks like the tools available are CoPP and 'mls ip cef rate-limit' to limit
> traffic punted the MSFC, and the 'mls rate-limit' options, some of which are
> enabled by default.

CoPP is the tool for the job, of course you should also implement iACL
and iPolicer in IXP/Transit borders.
 '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,
consider control-plane can take DoS of say 20kpps before dying,
by 'mls ip cef rate-limit' you can make the box die sooner, nothing
else really, as you do not differentiate between rate-limited good
or bad traffic. I've tried hard to understand why it's there, but
have been unable to figure it out. 

> Is there anything on the 6500/7600 like 'receive ACLs' on the 12k, or CoPP
> with a drop in the policy map for unwanted traffic is the best best to do
> this ?

 I'd say CoPP with penultimate rule of dropping all IP (ultimate rule,
catch-all is needed to allow IS-IS). No such 'receivei ACL' exists,
which should make you feel all warm and fuzzy inside. You can not
protect GSR/IOS properly in control-plane. CoPP like rACL are not
done in hardware there, but in LC CPU, which regardless of engine
is fairly trivial with bit of architectural insight to kill 
with quite low pps, and even with 0 clues, shouldn't take much
more than 200-300kpps.
 I've pushed almost 30Mpps to PFC3 control-plane of various
kind of traffic, keeping IS-IS, LDP, iBGP and telnet happily
unaware of the event.

> Also, is there a way to view the rate and therefore basline legit traffic
> punted to the MSFC in order to come up with a meaningful value for 'mls ip
> cef rate-limit' for a given network  ?

 My advise is never use 'mls ip cef rate-limit', I'm very keen to hear
of practical scenario where it does more good than bad.
 CoPP works, it's done in hardware but requires some planning indeed.
I've found out few CoPP bugs, here's most of them I think:

CSCsg85740 - CoPP with 'mls rate-limit all mtu-failure' rate-limits
             packets to control plane that are 18bytes short of real
	     limit. Not really much of an issue for me.

CSCsf30913 - When CoPP is deployed first packet goes though CoPP
             rules no matter what. Perhaps more curiosity than
	     real concern.

CSCsf96383 - Fails to program CoPP at hardware, ran only in MSFC.
             This is quite harmful, I've made short perl script
	     that each morning checks that CoPP is properly
	     programmed to hardware. For me this happens almost
	     always when box boots and sometimes when CoPP
	     is configured in fresh box.

CSCse90832 - If you have rule with multiple ACL matches, if one
             of them has explicit deny in end, it's positive
	     match, and no further rules are considered.
	     Consider that you have MGMT ACL first, which
	     has last rule of 'deny ip any any'. If subsequent
	     classes would allow eg. LDP, LDP would never come up,
	     as 'deny ip any any' would catch-all. Just use implicit
	     deny and you're home free.

CSCsf25709 - If you have CoPP with class-default, VPN-CAM in superman
             is never populated, that is, you get packets recirculated
	     more often in L3 MPLS VPN than what would be optimal.
	     This is platform restriction as far as I know, and can't
	     be worked around. Either don't use class-default (you 
	     only really need it, if you run IS-IS) or don't care about
	     the additional recirculations.

X	   - CoPP does not work if explicit-null is configured, this
             is almost universal to IOS, incoming packet is labeled,
	     as '0' and hence never matches CoPP rules. Fortunately
	     in 7600 CoPP works even with explicit-null. I'm not
	     sure if there is any intent to change CEF operations
	     so that the 0 would be popped before CoPP is evaluated.
	     This is seen at least in VXR, NSE100 and AS5k, probably
	     in all other platforms except 7600.


> 
> 
> 
> Thanks,
> 
> anton
> _______________________________________________
> 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/

-- 
  ++ytti