The following points offer various optional guidelines that may help an operator decide how to leverage Distributed CPU Protection.
The rates in a policy assigned to a capture SAP should be higher than those assigned to MSAPs that will contain a single subscriber. The rates for the capture sap policy should allow for a burst of MSAP setups.
To completely block a set of specific protocols on a specific SAP, create a single static policer with a rate of 0 and map the protocols to that policer. Dynamic policers and local monitors cannot be used to simultaneously allow some protocols but block others (the non-zero rates in the monitor would allow all protocols slip through at a low rate).
During normal operation it is recommended to configure ‟log-events” (no verbose keyword) for all static policers, in the dynamic parameters of all protocols and for all local monitoring policers. The verbose keyword can be used selectively during debug, testing, tuning, and investigations.
Packet-based rate limiting is generally recommended for low-rate subscriber-based protocols whereas kb/s rate limiting is recommended for higher rate infrastructure protocols (such as BGP).
It is recommended to configure an exceed-action of low-priority for routing and infrastructure protocols. Marked packets are more likely to be discarded if there is congestion in the control plane of the router, but will get processed if there is no contention for CPU resources allowing for a work-conserving behavior in the CPM.
To assign a different dist-cpu-protection policy to a specific MSAP instance or to all MSAPs for a specific MSAP policy, the operator can assign a new dist-cpu-protection policy to the MSAP policy and then use the eval-msap tool:
A:nodeA>tools>perform# subscriber-mgmt eval-msap - eval-msap {policy msap-policy-name | msap sap-id}
If needed, an operator can determine which subscriber is on a specific MSAP by using the show service active-subs command and then filtering (‟| match”) on the MSAP string.
If protocol is trusted, and using the ‟all-unspecified” protocol is not required, then avoid referencing this protocol in the policy configuration.
If a protocol is trusted, but the all-unspecified bucket is required, then there are two options:
avoid creating a protocol so that it is treated as part of the all-unspecified bucket (but account for the packets from X in the all-unspecified rate and local-mon rate)
create this protocol and configure it to bypass