[nsp] MSFC2 protection and rate-limiting

[Andrew Fort]

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
>
> 
>
>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
>
>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).

>  
>
>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 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).

> 
>
>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.

-afort