cisco press router security strategies phần 5 ppsx

Control Plane Policing 247 classification ACL are not classified within the associated MQC class-map. This also applies to the implicit deny at the end of the ACL policy as well. The policy actions that are applied to the traffic classes are specified within the CoPP policy configuration as described in Step 4 a bit later. Step 3: Define Packet Classification MQC Class Maps Now you must create class maps to complete the traffic-classification process using the previously defined ACLs from Step 2 to categorize IP packets into discrete classes. MQC class maps permit multiple match criteria, as well as nested class maps. The MQC match- any keyword requires that packets meet only one match criteria to be considered “in the class,” whereas the MQC match-all keyword requires that packets meet all of the match criteria to be considered “in the class.” If neither match-any nor match-all is specified, the default behavior is consistent with the match-all keyword. MQC match-not provides criterion that prevents a packet from being included in the class. In general, a match-all classification scheme with a simple, single-match criteria will satisfy initial deployments for CoPP. This is illustrated in Example 5-12 and leaves open the option for fine-tuning through multiple match criteria in the longer term. In general, traffic destined to the undesirable class should follow a “match-any” classification scheme. Further, creating class maps with descriptive names also simplifies deployment and operational complexity. Using the ACLs defined in Step 2, Example 5-13 constructs class maps for the specific traffic classes defined. Example 5-12 Sample IOS MQC Class Map Format Router(config)# class-map match-all { class-map-name } Router(config-cmap)# match access-group { acl-number } Example 5-13 Sample IOS CoPP Traffic Classes Defined Using ACLs ! Define a class for each type of traffic and associate the appropriate ACL ! Define a class-map to collect routing traffic… class-map match-all CoPP-routing match access-group 120 ! Define a class-map to collect management traffic… class-map match-all CoPP-management match access-group 121 ! Define a class-map to collect other normal traffic (icmp’s etc.) class-map match-all CoPP-normal match access-group 122 ! Define a class-map to collect undesirable traffic (attacks, etc.) class-map match-any CoPP-undesirable match access-group 123 ! Define a class-map to collect all remaining IP traffic class-map match-all CoPP-remaining-IP match access-group 124 ! 248 Chapter 5: IP Control Plane Security Step 4: Define the CoPP Service Policy Once the MQC class maps are defined in Step 3, they can be used to define policies to enforce each traffic class by referring to them within an MQC policy-map. The MQC policy map is used to associate specific policy actions with specific traffic classes. Two MQC commands are supported within CoPP policy maps, police and drop. Within IOS Software Release 12.0S, only the police command is available. However, drop may be used as an action within the police command for each of the conform-action, exceed-action, and violate-action arguments. This is similar to how traffic flows are permitted within CoPP policies except the permit action is used within the police command instead of drop. Example 5-14 illustrates a CoPP policy with four distinct traffic classes. As illustrated in Example 5-14, all traffic associated with class1 and class2 is filtered (discarded). Traffic associated with class3 is rate limited to 10 kbps and traffic associated with class4 is allowed with no maximum rate limit specified. The 20-kbps rate specified for class4 is insignificant given the exceed-action is transmit. For more detailed information on MQC, refer to the white paper “Cisco Modular Quality of Service Command Line Interface” (listed in the “Further Reading” section). Refer to Chapters 4 and 7 for a discussion on QoS security techniques and the QoS services plane, respectively. Typical deployments for CoPP use the general format shown in Example 5-15, where {action} is transmit or drop. Example 5-14 Sample IOS CoPP Drop, Rate-Limit, and Transmit Action Formats ! policy-map copp-in class class1 drop class class2 police 8000 conform-action drop exceed-action drop class class3 police 10000 conform-action transmit exceed-action drop class class4 police 20000 conform-action transmit exceed-action transmit ! control-plane service-policy input copp-in ! Example 5-15 IOS MQC Policy Map Template Router(config)# policy-map { policy-map-name } Router(config-pmap)# class { class-map-name } Router(config-pmap-c)# police { rate } [ burst-normal ] [ burst-max ] conform-action { action } exceed-action { action } Control Plane Policing 249 For new CoPP deployments, it is best to start out with a basic, forgiving policy that does not police (rate limit) any traffic classes, with the exception of the CoPP-undesirable class, until you confirm that all protocols are properly classified among class maps and that no authorized traffic has been overlooked. An overly constraining policy can result in network issues, such as loss of management connectivity, or more impacting conditions, such as loss of routing protocols and link state. This is especially true for the catch-all CoPP- remaining-IP class and the always-present class-default class. One deployment approach is to start out with conform-action transmit exceed-action transmit on all class maps except CoPP-undesirable, and tighten from there once operational experience is gained. Example 5-16 illustrates the CoPP policy configuration using the traffic classes defined previously. It is highly recommended that you start out with a pilot deployment on a few representative routers to gain experience and an understanding of traffic rates within each class map. Note that the police command rates used in Example 5-16 are for illustration purposes only. You must determine what the appropriate rates are for your network. Guidance on performing this task follows shortly. Based on Example 5-16, there are several critical things you need to know about policy- map CoPP and its construction for use with CoPP: • The class CoPP-undesirable is defined first. As with all MQC policy maps, class maps are processed in order and, hence, the order in which you arrange class maps within the policy map is critical to the operational effectiveness of CoPP. As soon as a match occurs, no further packet classification processing occurs with the current or any subsequent class maps. That is, a packet can be classified as belonging to only a single class map, and it is the first class map during which a match is determined. Therefore, because the desired policy is to deny fragments to the IOS process level on the RP, and fragments are included in the CoPP-undesirable class, this class must be defined Example 5-16 Sample IOS CoPP Policy Configuration ! Define a policy-map for CoPP… policy-map CoPP class CoPP-undesirable police 8000 1500 1500 conform drop exceed drop class CoPP-routing police 125000 1500 1500 conform transmit exceed transmit class CoPP-management police 50000 1500 1500 conform transmit exceed transmit class CoPP-normal police 15000 1500 1500 conform transmit exceed transmit class CoPP-remaining-IP police 8000 1500 1500 conform transmit exceed transmit class class-default police 8000 1500 1500 conform transmit exceed transmit ! 250 Chapter 5: IP Control Plane Security first (with a drop policy) to prevent noninitial fragments from reaching the IOS process level. If the CoPP-undesirable class is not defined prior to other classes, fragmented packets may be matched by an earlier class map and handled by that class map’s policy action. This applies to all undesirable traffic as well. Thus, the CoPP- undesirable traffic class should be specified first within the CoPP policy map configuration to prevent undesirable traffic from being mistakenly classified into another CoPP traffic class. • The class CoPP-remaining-IP is defined second from last. Because class maps are processed in order, any IP traffic that is not explicitly matched by entries ahead of class CoPP-remaining-IP will be matched by this class. There are two main reasons why you want to define a catch all IP class immediately prior to class-default. First, exception IP transit traffic must be handled by the IOS process level but cannot be matched by explicit policies (for example, Router Alert option). Because some attack vectors attempt to exploit this, it is recommended that this catch all IP class be defined to appropriately rate limit this traffic class. Second, and equally as important, if this catch-all IP class is not defined, then all of these transit IP and exception IP traffic flows will fall into the class-default class. As you will see next, because other non-IP traffic also falls into class-default, it is not recommended that class-default be rate limited. Thus, without the catch-all IP class CoPP-remaining-IP, you would be unable to prevent transit IP and exception IP traffic from adversely impacting L2 protocol traffic, including keepalives. • The class class-default is automatically placed last in the policy map. Any traffic that does not match any of the defined class maps previously described automatically falls into the class class-default. MQC class-default is a special class that is automatically defined and always included in MQC policies, whether it is specified by name or not. If it is not explicitly specified, it is still included but is not policed in any way. If it is included, as it is in Example 5-16, then an appropriate police action must be specified. In the current CoPP implementation (all IOS versions), the only Layer 2 protocol that can be matched by MQC within CoPP is ARP. (When ARP is not specifically classified, as it is not in Example 5-13 above, it will also fall into the class-default class.) All other non-IP and Layer 2 control plane packets will also fall into class- default. Non-IP and Layer 2 traffic includes Layer 2 keepalives, CLNS, as well as (at the time of this writing) MPLS labeled packets handled at the IOS process level, including those with the Router Alert Label or having an aggregate label that requires a second-level packet header lookup. Because of this, class-default should never be policed. As mentioned previously, this is why the class map immediately prior to class-default must be a catch-all for all remaining and unclassified IP traffic. This guarantees that class-default only contains non-IP and Layer 2 control plane traffic, and that it can safely be left unpoliced. You may also consider defining a distinct CoPP traffic class for ARP traffic, as illustrated in Example 5-17, to isolate ARP traffic Control Plane Policing 251 from other types of Layer 2 traffic. A distinct CoPP class for ARP traffic would then limit the aggregate rate of ARP traffic received, thereby helping to mitigate the risk of ARP attacks. • Finally, it is critical to note that, while CoPP policies are defined using MQC syntax, which is generally used for QoS services, this same usage within CoPP does not guarantee the specified bandwidth to the IOS process level for the relevant class. Rather, it is used to limit the bandwidth to the IOS process level that any one traffic class can consume. Also note that the configured maximum rate is the aggregate limit for all traffic associated with the specific class. Consider the case where the ACL used in a rate-limited class combines several protocols—for example, ACL 121 of Example 5-11 above used in the class CoPP-management. Each of those individual protocol’s entries then is capable of consuming the entire amount of bandwidth dedicated to this class. Hence, under attack, it may not be possible to use one configured protocol if another one within the same class is consuming all of the allocated bandwidth. Using ACL 121 and the class CoPP-management as an example, suppose that SNMP was leveraged within a DoS attack and consumed the allocated bandwidth assigned to the CoPP-management class. In this case, you might find it difficult using SSH to gain remote access into the router. Thus, constructing class maps with ACLs that match a single protocol may be reasonable in certain cases (for example, SSH) to provide more-assured availability under attack. Note that if a class is not rate limited, as is the case with the class CoPP-routing of Example 5-16 above, then the class has no maximum limit and one protocol cannot starve another within the same class map. Traffic classes that are not policed are justifiable in certain cases (for example, routing). However, normal traffic that is expected but not essential for network operations should be policed to mitigate the risk of a heavy load of normal traffic from adversely affecting routing and management protocols. Step 5: Apply the Service Policy to the Control Plane The final step in deploying CoPP is to attach the policy map developed in Step 4 to the logical receive interface. The general commands for applying the CoPP policy in the input direction are illustrated in Example 5-18. Example 5-17 Sample IOS CoPP Traffic Classes Defined for ARP Traffic ! Define a class-map to collect ARP traffic… class-map match-all CoPP-arp match protocol arp Example 5-18 IOS CoPP Policy Attachment ! Attached the CoPP policy to the control plane interface control-plane service-policy input CoPP ! 252 Chapter 5: IP Control Plane Security This generalized form is available on all router platforms that support CoPP. The Cisco 12000 series includes an additional distributed mode of CoPP. This and other 12000- specific CoPP deployment guidelines are described later in this section. Now that you have learned about CoPP policy construction methods, let’s turn the attention toward CoPP policy tuning. Tuning CoPP Policies Policy construction is the key to operational success with CoPP. Policies will need to be adjusted over time, however. It is possible that adjustments such as adding class maps or adding or modifying ACLs may be required, especially as new routers and services are deployed. However, the primary effort that likely will be required is to make adjustments to the rate limits applied to policy map classes. Questions on how to best tune policy rate limits are the most frequently asked by network operators, and thus will be the main focus here. When a CoPP policy is initially deployed, as previously mentioned, the initial policers should be conform transmit exceed transmit on all classes, except CoPP-undesirable. You can then use the results of the show policy-map command to understand the baseline measurements of the current traffic rates for each class within the policy map. After the production CoPP policy is deployed, you use these same techniques to validate rate-limit settings and fine-tune policies as necessary. The show policy-map command provides several keywords that help refine the output to information specific to the control plane. Some of the more important commands include the following: • Verify and review the CoPP service policy map configuration and status: show policy-map control-plane [all] [input [class { class-name }] | output [class { class-name }]] • Verify/review (all) policy map(s) configured on the router: show policy-map [ policy-map-name ] • In addition to the show policy-map command, the show class-map command also provides invaluable information. Verify/review (all) class map(s) configured on the router: show class-map [ class-map-name ] • Finally, reviewing the ACE counters on the access lists associated with class maps provides a wealth of information in terms of how effectively your policies are constructed to classify appropriate traffic. If you see a large number of hits against the ACL used in the catch-all IP class CoPP-remaining-IP, you should review the traffic types that are hitting this class and potentially modify other class map ACLs as appropriate to explicitly classify this traffic. Verify/review (all) access lists (associated with the class maps): show access-lists [ ACL-number ] Control Plane Policing 253 Example 5-19 shows a sample of the output generated by the show policy-map control- plane input command. As you can see, this output lists, per class map, the packet rates for matching traffic that both conforms or exceeds the policy, the names of the traffic classes and match criteria (ACLs in this case), and the policy action (police). These results should provide valuable guidance for policy tuning. Example 5-19 Sample show policy-map Output Detailing CoPP Class Statistics Router# show policy-map control-plane input Control Plane Service-policy input: CoPP (225) Class-map: CoPP-undesirable (match-any) (4988273/4) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 123 (4791698) 0 packets, 0 bytes 5 minute rate 0 bps police: cir 8000 bps, bc 1500 bytes conformed 0 packets, 0 bytes; actions: drop exceeded 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps Class-map: CoPP-routing (match-all) (7222977/1) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 120 (11449986) police: cir 125000 bps, bc 1500 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: transmit conformed 0 bps, exceed 0 bps Class-map: CoPP-management (match-all) (10957137/3) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 121 (5208466) police: cir 50000 bps, bc 1500 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: transmit continues 254 Chapter 5: IP Control Plane Security Example 5-20 shows sample output generated by the show access-lists command. As you can see, this output lists the ACE classification rules associated with each ACL and nonzero hit counts per ACE rule. The output of Example 5-20 accounts for 1000 ping packets sent to the router and permitted by the CoPP policy. conformed 0 bps, exceed 0 bps Class-map: CoPP-normal (match-all) (12606385/2) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 122 (8647266) police: cir 15000 bps, bc 1500 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: transmit conformed 0 bps, exceed 0 bps Class-map: CoPP-remaining-IP (match-all) (1062113/5) 40 packets, 8589 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: access-group 124 (10461554) police: cir 8000 bps, bc 1500 bytes conformed 40 packets, 8589 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: transmit conformed 1000 bps, exceed 0 bps Class-map: class-default (match-any) (9318433/0) 18 packets, 46123 bytes 5 minute offered rate 6000 bps, drop rate 0 bps Match: any (4397474) 18 packets, 46123 bytes 5 minute rate 6000 bps police: cir 8000 bps, bc 1500 bytes conformed 8 packets, 1383 bytes; actions: transmit exceeded 10 packets, 44740 bytes; actions: transmit conformed 0 bps, exceed 6000 bps Router# Example 5-19 Sample show policy-map Output Detailing CoPP Class Statistics (Continued) Control Plane Policing 255 SNMP queries may also be used to automate the process of gathering CoPP service policy transmit and drop rates. The Cisco QoS MIB CISCO-CLASS-BASED-QOS-MIB provides the primary mechanisms for MQC-based policy monitoring via SNMP. The implementation of this MIB is IOS release-dependent. Example 5-21 and Example 5-22 show simultaneous sample outputs generated by the show policy map control-plane IOS command and the snmpwalk SNMP command, respectively, and that indicate identical statistics for each class within the policy map. Example 5-20 Sample show access-lists Output Detailing ACL Router# show access-lists Extended IP access list 120 permit tcp host 10.0.10.1 gt 1024 host 10.0.10.11 eq bgp permit tcp host 10.0.10.1 eq bgp host 10.0.10.11 gt 1024 established permit tcp host 10.0.20.1 gt 1024 host 10.0.20.11 eq bgp permit tcp host 10.0.20.1 eq bgp host 10.0.20.11 gt 1024 established permit tcp host 209.165.200.13 gt 1024 host 209.165.201.1 eq bgp permit tcp host 209.165.200.13 eq bgp host 209.165.201.1 gt 1024 established permit ospf 10.0.0.0 0.0.255.255 any precedence internet Extended IP access list 121 permit tcp 10.0.30.0 0.0.0.255 10.0.20.0 0.0.0.255 eq 22 permit tcp 10.0.30.0 0.0.0.255 eq 22 10.0.20.0 0.0.0.255 established permit udp 10.0.30.0 0.0.0.255 10.0.20.0 0.0.0.255 eq snmp permit udp host 10.0.40.1 eq domain 10.0.20.0 0.0.0.255 permit tcp host 10.0.40.2 10.0.20.0 0.0.0.255 established permit udp host 10.0.40.3 10.0.20.0 0.0.0.255 eq ntp permit tcp host 10.0.40.4 eq ftp 10.0.20.0 0.0.0.255 permit udp any gt 10000 any gt 10000 Extended IP access list 122 permit icmp any any echo (1000 matches) permit icmp any any echo-reply permit icmp any any ttl-exceeded permit icmp any any unreachable permit icmp any any port-unreachable permit icmp any any packet-too-big Extended IP access list 123 permit tcp any any fragments permit udp any any fragments permit icmp any any fragments permit ip any any fragments permit udp any any eq 1434 Extended IP access list 124 permit ip any any Router# ! 256 Chapter 5: IP Control Plane Security The bottom line is, you should review and tune your CoPP service policies based on the statistics learned through the use of IOS CLI show commands and/or management station snmp queries. You should review service policy transmit and drop rates to ensure that the appropriate traffic types and rates are receiving the appropriate policing policy. The IOS command show policy-map control-plane is invaluable for reviewing and tuning site- specific policies and troubleshooting CoPP. This displays dynamic information about the number of packets (and bytes) conforming or exceeding each policy definition. This command is useful for ensuring that appropriate traffic types and rates are reaching the IOS process level on the RP. You should also review the output of the IOS command show access-list, which displays hit counts on a per-ACE basis. The presence or absence of hits indicates flows or lack thereof for that packet type reaching the IOS process level. Large numbers of packets or an unusually rapid increase in rate of packets processed may be suspicious and should be investigated. The lack of packets may also indicate unusual behavior, or that a rule may need to be revisited. Example 5-21 Sample show policy-map control-plane Output Detailing CoPP Class Statistics Router# sh policy-map control-plane input | include packets 0 packets, 0 bytes conformed 0 packets, 0 bytes; actions: exceeded 0 packets, 0 bytes; actions: 0 packets, 0 bytes conformed 0 packets, 0 bytes; actions: exceeded 0 packets, 0 bytes; actions: 1058 packets, 110704 bytes conformed 88 packets, 9824 bytes; actions: exceeded 970 packets, 100880 bytes; actions: 1002 packets, 104196 bytes conformed 21 packets, 2172 bytes; actions: exceeded 981 packets, 102024 bytes; actions: 6799 packets, 1398439 bytes conformed 6791 packets, 1394827 bytes; actions: exceeded 8 packets, 3612 bytes; actions: 2923 packets, 7505870 bytes conformed 1285 packets, 177458 bytes; actions: exceeded 1638 packets, 7328412 bytes; actions: Router# Example 5-22 Sample snmpwalk Output Detailing CoPP Class Statistics unix-station$ snmpwalk -v 2c -c cisco 10.82.69.121 .1.3.6.1.4.1.9.9.166.1.15.1.1.2 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.2.225.1062113 = Counter32: 6799 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.2.225.4988273 = Counter32: 0 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.2.225.7222977 = Counter32: 0 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.2.225.9318433 = Counter32: 2923 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.2.225.10957137 = Counter32: 1058 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.2.225.12606385 = Counter32: 1002 unix-station$ [...]... 1 25 permit ip any 10.0.0.0 0. 255 . 255 . 255 ! ! Define a class-map to collect ACL 1 25 traffic… class-map match-all CoPP-bad-receive match access-group 1 25 ! Define the new policy-map for CoPP… policy-map CoPP-extra class CoPP-undesirable police 8000 150 0 150 0 conform drop exceed drop class CoPP-routing police 1 250 00 150 0 150 0 conform transmit exceed transmit class CoPP-management police 50 000 150 0 150 0... 209.1 65. 200.2 25/ 32 and 192.168.0.0/16, respectively Example 5- 25 Sample IOS IP Receive ACL Policy ip receive access-list 100 access-list 100 deny ip any any fragments access-list 100 deny tcp any any eq 23 precedence internet access-list 100 permit ospf 192.168.0.0 0.0. 255 . 255 192.168.0.0 0.0. 255 . 255 precedence 6 access-list 100 permit tcp 209.1 65. 200.2 25 209.1 65. 200.226 eq bgp precedence 6 access-list 100 deny... same amount, as illustrated in Figure 5- 11 Figure 5- 11 GTSM for eBGP Multihop BGP Peer IP TTL = 255 Internet Attacker IP TTL = 255 eBGP Multi-Hop Peers with GTSM Enabled and Hop Count = 5 Private IP Network 276 Chapter 5: IP Control Plane Security To attack a directly connected eBGP session, the attacker needs to be directly connected to spoof an IP TTL value of 254 Similarly, to attack a multihop eBGP... Advertisement 209.1 65. 200.224/29, LOCAL-PREF = 110 209.1 65. 200.232/29, LOCAL-PREF = 110 209.1 65. 200.240/29, LOCAL-PREF = 110 209.1 65. 200.248/29, LOCAL-PREF = 110 ISP-2 ISP-1 IP Routing Table 209.1 65. 200.224/29, Next Hop = ISP-2 209.1 65. 200.232/29, Next Hop = ISP-2 209.1 65. 200.240/29, Next Hop = ISP-2 209.1 65. 200.248/29, Next Hop = ISP-2 Private IP Network ISP-1 209.1 65. 200.224/27 ISP-3 209.1 65. 200.224/27,... CoPP-management police 50 000 150 0 150 0 conform transmit exceed transmit class CoPP-normal police 150 00 150 0 150 0 conform transmit exceed transmit class CoPP-bad-receive police 8000 150 0 150 0 conform transmit exceed drop class CoPP-remaining-IP police 8000 150 0 150 0 conform transmit exceed drop class class-default police 8000 150 0 150 0 conform transmit exceed transmit ! Because classes are processed top-down within... succeed against the IP TTL check provided by GTSM Neighbor Authentication 2 75 Figure 5- 10 BGP TTL Security Check (or GTSM) eBGP Peers with GTSM Enabled IP TTL = 254 Internet Private IP Network Spoofed BGP attack packets discarded due to IP TTL check of GTSM BGP Attack IP TTL < 254 Attacker IP TTL = 255 GTSM supplies greater security for directly connected eBGP peers than it does for multihop eBGP peers,... address-family configuration mode The neighbor router must have the same MD5 key value Historically, changing a BGP MD5 key automatically caused BGP to reset the TCP protocol session (meaning the BGP session was also reset), which made it very difficult to dynamically manage MD5 keys in SP networks As of 12.0(23)S, 12.2( 15) T, 12.2( 15) S, and later, BGP MD5 keys may be changed without causing a reset of... an IOS router against security attacks However, they both rely upon IP header information for packet classification, including, for example, IP source addresses As outlined in Chapter 2, spoofed attacks are often used to bypass such security policies Consider the restrictive IP rACL policy illustrated in Example 5- 25, which only allows BGP and OSPF protocol packets sourced from 209.1 65. 200.2 25/ 32 and... misconfigurations, not security attacks Therefore, plaintext authentication will not be covered further MD5 helps to protect against both The required IOS configuration of MD5 authentication differs depending upon the specific protocol: • BGP: BGP supports only MD5-based authentication and is configured on a neighbor or peer group basis using the neighbor password command in IOS router configuration mode or router address-family... disabled by default and applies only to unicast traffic • Layer 3 security features: Some Catalyst 650 0 and Cisco 7600 security features are processed by first sending applicable packets to the MSFC For these security features, you need to rate limit the number of these packets being sent to the MSFC to reduce any adverse MSFC CPU impact The security features include authentication proxy (auth-proxy), IPsec, . tcp 10.0.30.0 0.0.0. 255 10.0.20.0 0.0.0. 255 eq 22 permit tcp 10.0.30.0 0.0.0. 255 eq 22 10.0.20.0 0.0.0. 255 established permit udp 10.0.30.0 0.0.0. 255 10.0.20.0 0.0.0. 255 eq snmp permit udp. CoPP-routing police 1 250 00 150 0 150 0 conform transmit exceed transmit class CoPP-management police 50 000 150 0 150 0 conform transmit exceed transmit class CoPP-normal police 150 00 150 0 150 0 conform. discarded) access-list 1 25 permit ip any 10.0.0.0 0. 255 . 255 . 255 ! ! Define a class-map to collect ACL 1 25 traffic… class-map match-all CoPP-bad-receive match access-group 1 25 ! Define the new policy-map