i have a n5k-5548up-af and as i read in https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/security/521_n1_1/b_5k_Security_Config_521N11/b_5k_Security_Config_521N11_chapter_01101.html#con_1078819 it has limited copp actions and we used the default copp and applied it in control-plane service-policy in copp-system-policy-customized , but when we send attacks (tcp syn or udp flood) towards 5548 interfaces cpu load reach %100 and i should deny the IP with acl , can anyone guide me how can i protect my control-plane? Thank you.
Segregating user traffic from management plane interfaces and traffic is also a good idea.
Where available, make use of the dedicated management ports, or make sure your switches don't have their management interfaces (often coming as SVIs, too) in the same VLAN or routing instance (VRF) used for user traffic. Make sure your routers don't expose services (SSH/Telnet, HTTP/HTTPS, SNMP etc) on the user facing interfaces/IP addresses at all. Bind these management services to the interfaces/ports/ips you want them on.
Heck, go all the way and carry user traffic on non-default VLANs in the context of Layer-2 forwarding ("switching") and the non-default routing table (read: in a VRF) in the context of L3-forwarding ("routing").
That alone reduces the attack surface considerably.
Then follow Ron Trunk's advice to make sure your infrastructure links (such as a point-to-point subnet between two routers) are not reachable from networks you don't trust, and that the routers/L3-Switches only expose the required set of listeners (colloquially: "open ports") on these interfaces (such as port tcp/179 for BGP, where needed).
Add the usual strong authentication mechanisms to the routing protocols, regardless if they share the interface with user traffic (which is sometimes unavoidable) or not.
Eventually, you can still resort to CoPP to make sure that the L3 switch or router's CPU is not kept busy generating ICMP unchreachables/replies or fragmenting packets.
And while you're at it: DoS attacks against your infrastruture might come at Layer2, too. Maliciously created STP Topology Change Notifications (causing a flush of the given MAC address table), attempts at becoming root for the given spanning-tree, or flooding your switches' CAM tables until they overflow, and certainly a few more.
So on your edge ports towards servers, make (well-educated!) use of portfast, bpduguard, bpdufilter, storm-control, as appropriate for the given trust level.
Also set limits for the number of learned/accepted MAC addresses on an edge switching port, and establish a policy of what to do with QoS flagged packets (ToS/DSCP) as they enter your network.
One solution to this problem is to block user or external access to your infrastructure addresses. You can apply an ACL to block access to the IPs of your infrastructure interfaces. For example, you can address all your infrastructure addresses (layer 3 interfaces) out of a specific IP range, and then deny that range from user or external sources.
Of course this is easier to do in a new installation, and hard to do after the fact, but it's a good way to prevent attacks like this.