[nsp] MSFC2 protection and rate-limiting

[Tim Stevenson]

Please see inline below:


At 07:52 PM 2/29/2004, cisco-nsp-request at puck.nether.net contended:
>Message: 12
>Date: Mon, 01 Mar 2004 14:45:39 +1100
>From: Andrew Fort <afort at choqolat.org>
>Subject: Re: [nsp] MSFC2 protection and rate-limiting
>To: flyman2 at mindspring.net
>Cc: cisco-nsp at puck.nether.net
>Message-ID: <4042B1E3.5040402 at choqolat.org>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>
>On 28/02/2004 2:53 AM, flyman2 at mindspring.net wrote:
>
>>In an effort to better protect our infrastructure I'd like to rate-limit the
>>traffic destined to my 6500/7600's MSFC2s.  So far I've found two possible
>>methods for doing so:
>>
>> 
>>
>>Mls ip cef rate-limit
>>
>>http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/software/122sx/
>>cmdref/m1.htm#75135
>>

This is the only method for sup2/msfc2. Control plane policing is not supported.


>> 
>>
>>Control Plane Policing
>>
>>http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guid
>>e09186a00801afad4.html 
>>
>> 
>>
>>However, the documentation on these two features isn't very useful.  I have
>>a number of questions I'm hoping the list members might be able to answer.
>>
>> 
>>
>>1)       In order to set mls ip cef rate-limiting or control plane policing,
>>one needs to determine what is an acceptable rate-limit to apply.  How can
>>you view the actual pps that an MSFC is receiving?  I've discovered the
>>following two commands that 'might' provide this information, but their
>>output does not match:
>>
>>a)       sh cef not-cef-switched
>>
>>b)       sh ibc


There is no simple way to get this information, unfortunately. Several iterations of sh ibc | in rx_input is probably the best way. 


>>
>>Is one of these the correct command?  A pps counter would be preferred over
>>these incremental counters.
>>
>>  
>>
>
>I dont know of a show command to tell you the rate.  Capture at
>reasonable intervals and do the first order analysis manually?
>
>Looking at the values of your SVI input queues (process switched queue)
>and the "show ip spd" output will give you some sort of idea.
>
>A high-watermark counter on these queues would be invaluable for gauging
>the impact of process switched network events, rather than simply seeing
>drops/flushes after the fact.  Cisco? :)
>
>To be honest, though, I found that almost any value of the rate and
>burst-values protected the MSFC reasonably well (with Sup720 at least).
>I'm using "40000 10" (Sup720 gives you a burst value also) in production
>and this withstood a many hundreds of Kpps tcp/179 SYN attack (initiated
>by a Smartbits).  Conversely (strangely), setting "60000" would protect
>against a 40kpps attack, while not setting anything would not protect
>against a 40kpps attack.  My feeling is that the context
>change/interrupt handling done by the MSFC when 'IP Input' is called is
>particularly expensive, but that doesn't really explain my results, either.
>
>Note I'm doing this on Sup720 and I'm not sure what differences exist in
>the punt protection functionality between the two architectures (it
>feels like it's not that much different, though).


Sup2 & sup720 are quite different, actually. Sup2 really just gives you one overall aggregate rate limiter, so there is no control over what kind of traffic consumes b/w on the inband channel. There are some other small enhancements as well (eg, fixed rate limit for traffic req'ing unrecahables, etc.) This is documented here:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/12_1e/swconfig/dos.htm

Sup720 lets you control the rate for a variety of different categories of traffic individually, so you can prevent certain types of traffic from consuming inband b/w at all, or throttle it back to a very low rate.

These are all configured using the mls rate-limit command, the commands are doc'd here:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/cmdref/m1.htm#59938




>>  
>>
>>2)       Is there any sort of prioritization deployable with cef
>>rate-limiting?  As I understand it, control plane traffic is a punt
>>(=not-cef-switched).  If this traffic is rate-limited during a DOS attack,
>>then valid control traffic will eventually get choked-off.  Control Plane
>>Policing appears to address this issue, however is there any other
>>difference between the two methods?
>>
>>  


"not-cef-switched" is for IOS/software CEF, in other words, we may be able to s/w cef-switch something that was punted to the RP CPU, so not sure if this will be an accurate guage of the aggregate of traffic hitting the RP.



>>
>
>Not AFAIK, you'd have to use one then the other. (I'm not doing this
>since it's not supported in 12.2(17a)SX* on Sup720 (control-plane), as
>far as I can see).


Right, not supported.


>> 
>>
>>3)       Is there traffic that reaches and gets processed by the MSFC2 that
>>is not considered to be a 'punt' by mls cef?  
>>  
>>
>
>Not as far as I know.  For something to be process switched, (ARP or IP
>Input), it has to be punted.


As you may or may not know, a final lookup result can come from one of three points in the h/w fwding engine: the h/w FIB/Adj is just one of these.

The other 2 are an ACL lookup and a NetFlow table lookup. So you could have a FIB TCAM entry for a prefix pointing to a non-punt adj entry, but still get punted due to an ACL TCAM or NF table lookup for a particular packet that points to a punt adj. So it is more correct to say that anything that goes to the RP CPU will have a punt adj, but that adj entry may not be associated with a prefix entry in the fib.

Tim



>-afort
>


Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Catalyst 6500
Cisco Systems, http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.