Logging

Logging can be used for fault identification, security auditing and network forensics. Logging aims to answer the three questions: what, when, who? Log messages are generated by the various services and protocols running on a network device. By default, output from system messages and debug commands is sent to a logging process. The logging process controls the distribution of logging messages to various destinations, such as the logging buffer, terminal lines, syslog server. Messages are also sent to the console. These are then viewed using syslog, local logging, debugs, conditional debugs. Logs are also used for forensics and compliance. It is important to note that the time must be consistent. This can be done by configuring NTP to provide accurate datetime values. Troubleshooting can be difficult if you cannot correlate timestamps across devices.

Logging Messages

Syslog messages can be output to the console, local buffer or remote syslog server. The messages follow this format:

%FACILITY-SUBFACILITY-SEVERITY-MNEMONIC: message text

Where:

• FACILITY-SUBFACILITY: protocol, module or process that generated the message.
• SEVERITY: This is a level from 0 - 7 that specifies how important the message is. When you enable logging for a specific level, it also enables all levels above it. For example, if you enable level 4(warnings), it also will enable levels 0 - 3.

  Level Number	Severity	Description	Syslog Definition
  0	Emergencies	System is unusable	LOG_EMERG
  1	Alerts	Action must be taken immediately	LOG_ALERT
  2	Critical	Critical conditions	LOG_CRIT
  3	Errors	Error conditions	LOG_ERR
  4	Warnings	Warning conditions	LOG_WARNING
  5	Notifications	Normal but significant conditions	LOG_NOTICE
  6	Informational	informational messages	LOG_INFO
  7	Debugging	debug-level messages	LOG_DEBUG

• MNEMONIC: a code that identifies the action reported
• Message text: A plain text description of the event

Local Logging

By default, all logging is displayed on the console. This can be turned off with the no logging command. By default, monitor and buffer logging display messages with severity levels of debugging and lower. For SSH/Telnet, the logging session settings can be configured using the command terminal monitor

Logging Console

To enable logging to console, use the command logging console. By default, the logging severity level for console is debugging. To control the logging options, use the command logging console <level>.

Logging Buffer

For local logging, Cisco IOS can save syslog messages to an internal buffer i.e., all the logs are saved on the device itself. You can display these messages by using the show logging command.

These messages are lost when the device is rebooted. The default buffer size is 8192 bytes. When the buffer is full, the older logs get overwritten by the newer ones. The size of the buffer can be increased using the command: logging buffered <size>.

Logging Monitor

To enable logging to remote logins via SSH or telnet, use the command logging monitor <level>. The default logging severity is debugging. However, by default, the log messages do not appear in the login session of of SSH or telnet. To view the log messages in the login session of a vty line, issue the command terminal monitor.

Logging messages can be disabled from a vty login session using the command terminal no monitor.

logging synchronous

The command logging synchronous [level <severity-level>|all] | limit <0-2147483647>. Enables synchronous logging of messages. It can be configured to prevent logging messages from interrupting the typing at a login session. The optional values:

• severity-level: indicates that messages with a severity level equal to or higher are printed asynchronously. The default is 2.
• limit: specifies the number of buffers to be queued for the terminal after which new messages are dropped. The default is 20.

Logging Flash

Logs can be stored as files on flash memory. This is accomplished using the command logging file flash:<file-name> &max-file-size> <min-file-size > <severity-level> where

• The maximum file size is in the range 4096 - 2147483647 bytes.
• The default size is 4096.
• The minimum file-size is in the range 1024 - 2147483647 bytes.
• The severity-level is in the range 0 - 7.

The command logging file flash:log_message.txt 40960 4096 3 stores log messages in a file in a flash memory.

Debug

Debugging is a powerful tool for troubleshooting complex network issues. It displays detailed information about all supported protocols and features of the network device. Use the debug command with caution, on production networks, as it is a resource intensive tool and may impact operations. Debugging can disrupt operations under high-CPU load conditions as debugging is processed by the CPU.

Best practices when using debugging include the following:

• show process cpu sorted: helps understand current CPU utilization. If the router is already loaded, debugging may impact the router.
• Consider output volume and time before enabling debug. If output is voluminous, this may impact router performance.
• Excessive console logging can cause the network device to hang as its CPU prioritizes this output. Use vty terminal monitor or logging buffered instead.
• Disable debug commands after troubleshooting using no debug all or undebug all.

Debugging messages can be enabled using the command debug <command>. The debugging messages can then be sent to a logging service, in this case the console using the command logging console.

The following is an example of the debugging of OSPF: debug ip ospf adj.

Debug using IP Access Lists

It allows debugging information that matches a configured IP access control list.

access-list 100 permit ip any 192.168.1.1 0.0.0.0
debug ip packet 100

Any debugs that do not match the access control list are not logged.

Conditional Debugs

Generates detailed information about a specific object such as matching a specific interface, username, MAC address, VLAN, etc. Limit the number of packets punted to the CPU. Conditional debugs are configured using the command debug condition <interface>. Conditional debugs can be stacked as such that the debugging messages that are displayed match all conditions in the stack.

debug condition gigabitethernet1/0
debug condition ip 1092.168.1.1
debug ip ospf hello

The above configuration will generate debug messages if they match all three commands.

To log debug messages for packets matching an ACL and specific interface: debug interface <interface-id>. Verify with show debug.

With conditional debugs, you can attach an access-list to filter debug traffic to permitted traffic in the acces-list.

Verification

show debug

After disabling the debug, ensure that the debug condition is disabled as well.

show debug

Enabled debugging can be viewed using this command.

Syslog

Logs generated by a device can be sent to a logging buffer whose size can be modified, or an off-box syslog collector. Syslog listens for log messages on UDP port 514. Syslog is the standard for computer message logging. It allows the separation of software which generates messages from the systems that store it and the software that analyzes and reports it. It can be used for the security auditing and system management, debugging messages and analysis. The syslog is supported by a wide range of devices, including routers and receivers over multiple platforms. The syslog is used to intergrate the log data from many various types of systems into the central repository.

Rate-limit: used to limit the rate of messages per second.

The syslogs can be forwarded to a syslog server using the following process

1. Specify the syslog server: logging host <ip-address>.
2. Specify the type of messages: the message type to be logged is specified using the command logging trap <severity>.

Filtering Logs

Logging Discriminator

A logging discriminator can be used to filter generated logs based on the text in the log. Log discriminators can be used to filter out specific logs that are repeatedly generated consuming the device log buffer. Some logs have a high severity level but are not so consequential such as up-down messages. It can be applied to the console, monitor, buffer or syslog server.

When creating a log discriminator, be as specific as possible and test the discriminator extensively before deploying it in a production environment. This will minimize the risk of filtering important messages.

To create a syslog message discriminator, use the command logging discriminator <discriminator-name> <facility> <mnemonics> <message-body> <includes> <severity> rate-limit> where:

• facility: (Optional) Message subfilter for the facility pattern in an event message.
• mnemonics: (Optional) Message subfilter for the mnemonic pattern in an event message.
• msg-body: (Optional) Message subfilter for the msg-body pattern in an event message.
• drops: Drops messages that match the pattern, including the specified regular expression.
• includes: Delivers messages that match the pattern, including the specified regular expression string.
• string: (Optional) Expression used for message filtering.
• severity: (Optional) Message subfilter by severity level or group.
• sev-num: (Optional) Integer that identifies the severity level or multiple levels. Multiple levels must be separated with a comma (,)/
• rate-limit: (Optional) Specifies a number of messages to be processed within a unit of time.
• msglimit: (Optional) Integer in the range of 1 to 10000 that identifies the number of messages not to be exceeded.

To configure a logging discriminator:

1. Configure the logging discriminator name and filtering options:
   logging discriminator msg-body drops Configured from console by console

2. Application:
   • To apply the logging discriminator to the console, use the command logging console discriminator <discriminator-name>
   • To apply the logging discriminator to the monitor, use the command logging monitor discriminator <discriminator>.

Verification

Configured logging settings can be viewed using the command show logging.

Timestamps

Timestamps are controlled by the service timestamps command. This command by itself enables the adding of timestamps to debug messages and, by default, sets the timestamps to uptime.

Having logs and debug messages timestamped is extremely important when troubleshooting particularly across different devices. To enable timestamps on logging and debug messages:

• service timestamps debug datetime msec: Adds timestamps to debug messages including milliseconds. The datetime option includes the date and the time.
• service timestamps log datetime msec: Adds the timestamps to logging messages. Options include:
  • datetime: This option alone enables the date (day of month and month) and time(hours, minutes and seconds). Additional options include:
    • localtime: use the local timezone for timestamps.
    • msec: include milliseconds in the timestamp.
    • show-timezone: add timezone information to the timestamp.
    • year: include the current year in the timestamp.
  • uptime: does not include additional options as does datetime.

Sequence Numbers

If there is more than one log message with the same time stamp, you can display messages with sequence numbers to view these messages. By default, sequence numbers in log messages are not displayed. Sequence numbers can be added to log messages using the command service sequence-numbers. When enabled, they are prepended to the log message appearing at the start of a log message.

IPv6 First Hop Security

Introduction and Overview

As IPv4 public addresses get depleted, the number of IPv6 deployments has increased exponentially. This exponential increase in the adoption of IPv6 can also be attributed to introduction of Internet of Things (IoT).

With all these devices gaining access to networks, security concerns are growing in IPv6 deployments. It is important that these IPv6 deployments are secured for optimum operation of these networks. A critical part of the network that needs to be considered when implementing security mechanisms is at the local links (Layer 2) where hosts are connected to the network.

First hop is the network segment between the end hosts and their default gateway i.e., the access layer. Security at the first hop aims to prevent against internal threats at the access layer such as a man-in-the-middle(MiM) attack. In IPv4, security at the access layer is implemented through DHCP snooping, IP source guard and dynamic ARP inspection. Most IPv6 first-hop security features are implemented on a layer 2 device(switch).

In IPv6, ICMPv6 ND/NDP replaces IPv4 ARP. ARP uses two messages: request and reply. With ICMPv6 ND uses four messages:

1. Neighbor Solicitation (NS): a device requests for information about a neighbor.
2. Neighbor Advertisement (NA): a device advertises its information to other neighbors.
3. Router Solicitation (RS): a device requests for information about local routers i.e., routers in the network segment.
4. Router Advertisement (RA): a device advertises itself as an active router.

When a host is added to a network:

1. The host chooses a link-local address; usually FE80::/10 for the network segment of the address. The host segment of the address is generated using EUI-64.
2. The host then checks to confirm that the link-local address is unique by sending an NS on the local link to the solicited node multicast address (FF02:0:0:0:0:1:FF00::/104 + 24 low-order bits from the EUI-64). If no response is received for the NS, then the link-local address is confirmed as unique.
3. The host then sends a NA to the "all hosts multicast address" FF02::1 (similar to 255.255.255.255 in IPv4) announcing itself as a host.
4. Router discovery is then attempted by sending RS messages to FF02::2 (all routers multicast address).
5. A local router replies with RA that contains the router's IPv6 address and MAC address along with prefix information for SLAAC.
6. The host chooses a global prefix for SLAAC where the address is generated using the RA advertised prefix and EUI-64 for the host part of the address. The host performs DAD to verify that the global prefix address is unique. If unique, the host sends a NA for the global prefix.

IPv6 First Hop Attack Surface

IPv6 features such as ICMPv6 Neighbor Discovery’s Neighbor Solicitation (NS), Neighbor Advertisement (NA) messages and Router Discovery Router Solicitation (RS) and Router Advertisement (RA) introduce attack options that were previously not possible in IPv4. IPv6 first hop security concerns on the local links are usually associated with router discovery, neighbor discovery, duplicate address detection(DAD), stateless address autoconfiguration(SLAAC) and DHCPv6.

This process presents several attack surfaces that can be exploited in some of the following ways:

• Spoof the router: a rogue device can send gratuitous RA to announce itself as the router. Spoofing the router is a MiM attack or a basic DoS attack
• Spoof DHCPv6 server: a rogue device can respond with bogus DHCPv6 messages. Spoofing the DHCPv6 server is a form of DoS attack or MiM if it is combined with RA spoofing.
• Poison the router's ND cache: a rogue device can send gratuitous NA messages with other device's addresses. Poisoning the router's ND cache is a MiM or DoS attack.
• Overload the router's ND cache: a rogue device sends packets to the entire /64 prefix range. This results in the DoS attack as router is overwhelmed trying to respond with NS messages.

RA Guard

Router discovery is a means for hosts to locate routers that reside on a local link. Security concerns with router discovery include attacks on ICMPv6 Router Discovery (RD) and host address allocation using SLAAC (Stateless Address Autoconfiguration). RD attacks are categorized as man-in-the-middle attacks.

Attack

One of the several ways that an RD attack may take place follows this sequence:

Host A sends a Router Solicitation (RS) message on its local link to discover local routers connected to its link.

A legitimate router R1 responds with a Router Advertisement (RA) with lifetime X to the RS from Host A. Host A installs R1 as its default gateway for duration X.

An intruder Rx inserts itself in the local link by connecting to one of the switchports on the local link switch or connecting to the wireless network common to R1 and Host A. Rx can then spoof R1’s RA messages and sends R1’s RA messages with a shorter lifetime Y.

When duration X is about to elapse, Host A request a renewal of the prefix lease.

Rx then sends new RA messages with lifetime Z. Host A will receive these RA messages and install Rx as its default gateway.

Host A starts to direct traffic to remote networks through Rx as its gateway. Rx can then monitor traffic from Host A.

The above sequence of events is an example of a man-in-the-middle (MiTM) attack on IPv6 local links.

IPv6 RA Guard

Router advertisements should enter a network through an authorized switchport and from an authorized source. RA Guard protects against router spoofing and prefix spoofing on the segment. This is accomplished by blocking or rejection of rogue or unwanted router advertisements that are received on certain ports.

Deploying RA Guard involves configuration of a policy and attaching the policy to a specific VLAN or switchport. Traffic is permitted on the ports that comply with the policy and blocked/dropped on non-compliant ports.

Configuration

When configuring RA Guard policies, device roles are specified for each of the ports that the policy will be applied. The configurable device roles include:

• host: attached device is a end-user host device. In host mode, all RA redirect messages are disallowed on the port.
• router: attached device is a router. RA and RS messages are to be expected from this port. Additionally, switchports with routers can be configured as trusted ports.
• monitor: for attached devices that have network monitoring features or are network sniffers.
• switch: attached device is a switch.

When configuring RA Guard, two policies are usually configured; one policy for ports where routers are attached and a separate policy for ports where hosts are attached.

1. Configure the RA Guard Policy:

   Defining a policy for hosts:

   1. Define the RA guard policy: ipv6 nd raguard policy <policy-name>
      SW1(config)#ipv6 nd raguard policy HOSTS

   2. Specify the device role: The device role can be host or router: device-role host.
      SW1(config-nd-raguard)#device-role host

   Creating a second policy for routers:

   1. Define the RA guard policy: ipv6 nd raguard policy <policy-name>
      SW1(config)#ipv6 nd raguard policy ROUTERS

   2. Specify the device role: The device role is router: device-role router.
      SW1(config-nd-raguard)#device-role router

   3. Configure the port as trusted: trusted-port
      SW1(config-nd-raguard)#trusted-port

   4. Enable of O flag/bit: other-config-flag on. The O bit indicates to the client additional information is to be extracted from another source such as a DHCP or DNS server.
      SW1(config-nd-raguard)#other-config-flag on

   5. All optional features are bypassed if not configured. They include:
      • hop limit <maximum | minimum> <number>: (Optional) Enable verification of advertised hop count limit.
      • managed-config-flag <on | off>: (Optional) Enable verification that the advertised managed address configuration flag is on.
      • match ipv6 access-list alc
      • match ra prefix-list ipv6_prefix_list: (Optional) Verification of the advertised prefixes in inspected messages from configured prefix-list.
      • other-config-flag <on | off> : (Optional) Verification of advertised other-config parameter
      • router-preference maximum < high | low | medium > : (Optional) Verification that the advertised default router preference parameter value is lower than or equal to a specified limit
      • match ipv6 access-list <acl>: (Optional) Enable verification of the sender’s IPv6 address in inspected messages from the configured authorized device source access-list

2. Apply the RA Guard policy to the switchport or VLAN:
   • VLAN:
     SW1(config)#vlan configuration 1
SW1(config-vlan-config)#ipv6 nd raguard attach-policy HOSTS


   • interface: Apply IPv6 RAGuard feature to a specified interface using the command ipv6 nd raguard attach-policy <policy-name> [vlan <add|except|none|remove|all> vlan <vlan1, vlan2 … vlan n>]
     SW1(config)#interface g0/0
SW1(config-if)#ipv6 nd raguard attach-policy ROUTERS


Verification

The following commands verify RA Guard configuration and operation:

• show ipv6 snooping policies: RA guard will appear as one of the snooping policies configured
• show ipv6 nd raguard policy <policy-name>
• debug ipv6 snooping raguard <filter | interface | vlanID>
• show ipv6 snooping capture-policy interface <interface-id>: for configured interfaces

Restrictions for IPv6 RA guard

• IPv6 RA guard does not offer protection when IPv6 traffic is tunneled.
• RA guard is supported on hardware when the TCAM is programmed.
• RA Guard can be configured on a switchport interface in the ingress direction.
• Supports host and router mode.
• Not supported in etherchannel and etherchannel port members.
• Not supported on trunk ports with merge mode.
• Is supported on auxiliary VLANs and private VLANs (PvLANs). Primary VLAN features are inherited and merged with port features.
• Packets dropped by IPv6 RA guard can be spanned.
• RA guard cannot be configured if the following command is configured platform ipv6 acl icmp optimize neighbor-discovery

SLAAC

SLAAC is a mechanism that enables an IPv6 host to obtain an IPv6 address prefix from its local router through one of its local links without the use of all DHCPv6 features. Unlike DHCPv6, due to the stateless nature of SLAAC, address assignments are not verified before addresses are issued.

Steps involved in a SLAAC attack:

1. Host A sends a Router Solicitation (RS) message on its local link to discover local routers connected to its link.
2. A legitimate router R1 responds with a Router Advertisement (RA) that provides the IPv6 prefix. 2001:DB8:C0FF:EE::/64 with lifetime X.
3. Host A configures the address 2001:DB8:COFF:EE::2/128 and checks the availability of the address using Duplicate Address Detection (DAD) and begins using this address.
4. An intruder Rx inserts itself in the local link by connecting to one of the switchports on the local link switch or connecting to the wireless network common to R1 and Host A. Rx can then spoof R1’s RA messages and sends R1’s RA messages with a shorter lifetime Y.
5. Host A’s IPv6 address will then expire at the lapse of duration Y.
6. Rx can then send a new RA with a new prefix 2001:DB9:COFF:EA::/64.
7. Upon receiving the new prefix, Host A will configure the address 2001:DB9:COFF:EA::09/128 with R1 still being retained as the default gateway. R1 may block Host A’s network traffic due to the fact that it is from an unknown network.
8. R1 may drop Host A’s traffic resulting in black-holing all network traffic from Host A.

DHCPv6 Guard

DHCPv6 assigns hosts IPv6 prefixes and other configuration options. DHCPv6 is both a stateful and stateless protocol. A rogue DHCPv6 server could be inserted into a network. The attackers can then deploy man-in-the-middle attacks ,traffic interception or blackhole traffic.

DHCPV6 Attacks

DHCPv6 does not assign a default router like DHCP in IPv4 environments. Th default router is learned through SLAAC from RA messages.

DHCPv6 Guard prevents the spoofing of the DHCPv6 server by blocking DHCPv6 messages that come from unauthorized / rogue DHCPv6 servers and relay agents. Client messages or messages sent by replay agents from clients are not blocked. When implementing DHCPv6 Guard, devices are categorized as server and client. DHCPv6 server messages are only processed if the device role is set to server.

Configuration

The configuration of the DHCPv6 Guard is similar to that of the RA Guard. A DHCPv6 Guard policy is configured for the DHCPv6 clients and a separate policy for the servers. The policy is then applied to a VLAN or interface.

1. Configure the DHCPv6 policy:

   Policy for servers:

   1. SW1(config)#ipv6 dhcp guard policy SERVERS
SW1(config)#device-role server
SW1(config)#trusted-port

      Additional configuration options exist for attached DHCPv6 servers:

      • Authorized DHCPv6 servers: DHCPv6 messages can be permitted to be transmitted if they originate from authorized DHCPv6 servers. To enable this feature:
        1. Configure an IPv6 access control list with the IPv6 addresses of the authorized DHCPv6 servers: ipv6 access-list <acl-name> permit host <ipv6-address> 128.
        2. Enable verification of the advertised DHCP server and relay address in inspected messages from the configured authorized server ACL. An empty ACL is treated as a permit. match server access-list <acl-name>.
      • IPv6 Addresses in Authorized Range: DHCPv6 Guard can be configured to permit DHCPv6 advertised prefixes are in the permitted IPv6 range:
        1. Create an entry in an IPv6 prefix-list; ipv6 prefix-list <prefix_list_name> permit <ipv6_prefix> 128.
        2. Enable verification of advertised prefixes in DHCP reply messages from the configured authorized prefix-list. An empty ACL is treated as a permit.

   Policy for clients:

   1. SW1(config)#ipv6 dhcp guard policy CLIENTS
SW1(config)#device-role client

   Other optional DHCPv6 features include:

   • preference min limit : Enable verification that the advertised preference (in preference option) is greater than the specified limit
   • preference max limit : Enable verification that the advertised preference is less than the specified limit

2. Apply the DHCPv6 Guard policy:
   1. Interface:
      SW1(config)#interface g0/0
SW1(config-if)#ipv6 dhcp guard attach-policy SERVERS


   2. VLAN:
      SW1(config)#vlan configuration 1
SW1(config-vlan-config)#ipv6 dhcp guard attach-policy CLIENTS

Verification

The operational state of DHCPv6 Guard can be verified using these commands:

• show ipv6 dhcp guard policy <policy-name>.
• show ipv6 snooping policies.

Restrictions

DHCPv6Guard is not supported on etherchannel ports.

Binding Table

The binding table is a database of IPv6 neighbors connected to a device and is created from informational sources such as ND snooping, DHCP gleaning. It contains information such as the link-layer address, the IPv4 or IPv6 address, and the prefix binding i.e., it can be considered to be a mapping of layer 2 addresses to IPv6 addresses. It is used by various IPv6 guard features to prevent spoofing and redirect attacks.

The binding table supports features that can be leveraged to provide first hop security:

• Limits can be set for the number of IPv6 addresses that a MAC address can have.
• The binding table recovery mechanism feature enables the binding table to recover in the event of a device reboot. The recovery mechanism will block any data traffic sourced from an unknown source (a source that is not in the binding table).
• The binding table introduces the capacity to provide a prefix-list that is matched before the recovery is attempted for both DHCP and NDP. If an address does not match the prefix-list associated with the protocol, the recovery of the binding table entry will not be attempted with that protocol.

IPv6 Snooping

IPv6 snooping bundles several IPv6 first-hop security features such as ND inspection, IPv6 device tracking, IPv6 address glean, IPv6 binding table recovery. IPv6 ND inspection operates at Layer 2 or between Layer 2 and Layer 3. IPv6 snooping mitigates vulnerabilities in the ICMPv6 ND mechanisms for example attacks on DAD, address resolution, device discovery and neighbor cache/table. IPv6 snooping learns and secures binding for SLAAC addresses in Layer 2 neighbor tables and analyses ND messages in order to build a trust binding table. An ND message is considered trustworthy if its IPv6-to-MAC mapping is verifiable. The IPv6 first-hop security binding table recovery mechanism enables the binding table to recover in the event of a device reboot.

The binding table is a database of IPv6 neighbors connected to the device and is created from sources such as ND snooping. It is used by various IPv6 guard features to validate link-layer addresses, IPv4 or IPv6 addresses prefix-binding of neighbors to prevent spoofing and redirect attacks.

Configuration

To configure an IPv6 snooping policy;

1. Configure the snooping policy:
   SW(config)#ipv6 snooping policy SNOOP_POLICY


2. Attach the snooping policy to an interface:
   SW(config)#interface g0/0
SW(config-if)#ipv6 snooping attach-policy SNOOP_POLICY


Verification

• show ipv6 snooping capture-policy interface <interface_number>: To display snooping ND messages and capture policies
• show ipv6 snooping counter interface <interface_name_number> : To display information about the packets counted by the interface counter
• show ipv6 snooping features : To display information about snooping features configured on a device
• show ipv6 snooping policies : To display information about configured policies and interfaces that they are attached to
• debug ipv6 snooping : Debugging of IPv6 snooping information

Restriction

IPv6 snooping is not supported on etherchannels.

Source Guard

If a device starts transmitting on a network segment without IPv6 host discovery messages such as NS, NA, DHCPv6 message exchange, source guard enables the switch to drop such traffic from an unfamiliar IPv6 source address.

IPv6 source guard relies on IPv6 snooping cache to create the IPv6 neighbor binding table. It creates an automatic IPv6 port ACL(PACL) to filter sources based on neighbor binding table.

Configuration

1. Configure the source guard policy:
   SW(config)#ipv6 source-guard policy SG_POLICY
SW(config-sisf-sourceguard)#permit link-local
SW(config-sisf-sourceguard)#deny global-autoconf
SW(config-sisf-sourceguard)#trusted

2. Apply the configured source guard policy to the VLAN or interface:
   • On the VLAN:
     SW(config)#vlan configuration 1
SW(config-vlan-config)#ipv6 source-guard attach-policy SG_POLICY

   • On the interface:
     SW(config)#interface g0/0
SW(config-if)#ipv6 source-guard attach-policy SG_POLICY

Verification of Source Guard

The following command is used to verify IPv6 source guard: show ipv6 snooping policies.

Neighbor Discovery Attacks

Similar to RA messages ND messages are used to discover other hosts on the local link. It replaces ARP in IPv6. ND performs DAD and address resolution, neighbor unreachability and redirection. Neighbor discovery messages are mainly Neighbor Solicitation (NS) and Neighbor Advertisement (NA). ND Attacks usually involve Address Resolution, Duplicate Address Detection and Neighbor Cache attacks.

Address Resolution Attacks

Address resolution is the process that a host (Host A) follows when it wants to send network traffic to another host (Host B) on the local link when it does not know its Layer 2 address (MAC address in Ethernet networks). Host A resolves the IPv6 address of Host B into a MAC address and forwards the packet with Host B’s MAC address as the destination address of the Layer 2 frame.

Stages in IPv6 address resolution attacks include the following;

1. Host A sends a Neighbor Solicitation message on the local link requesting for Host B’s link local address. Host B sends a Neighbor Advertisement (NA) message on the local link containing its MAC address which Host A stores in its neighbor table binding the MAC address with the IPv6 address.
2. If a malicious Host X inserts itself into the local network, it can masquerade as Host B and intercept all packets sent to Host B. Without effective IPv6 first-hop security, Host X can perform a Man-in-the-Middle (MiTM) attack.
3. Host A will attempt to send packets destined to Host B but using Host X’s link-layer address.

Duplicate Address Detection Attacks

Duplicate Address Detection (DAD) is an IPv6 protocol that enables a host to detect a duplicate address on the local network. DAD attacks are usually aimed at preventing hosts from having IPv6 addresses. Steps involved in deploying a DAD attack;

1. Host A wants to use the address 2001:DB8:C0FF:EE::1. So it sends an NS message on its local link to determine if any other host is using this address. If no NA response is received from other hosts on the local link, Host A will go ahead to use this address.
2. However, malicious host Host X which has inserted itself on the local link receives this NS message. It responds with an NA claiming that it is currently using that same address 2001:DB8:C0FF:EE::1 yet it does not actually use this address.
3. Host A sends another NS message requesting to use another IPv6 address 2001:DB8:C0FF:EE::A. Host X again claims that this address is already taken. Host X essentially claims all addresses that Host A requests to use thereby preventing Host A from having a valid IPv6 address.

Neighbor Cache Attacks

When performing address resolution after receiving IPv6 an NA response to an NS request, a host stores the MAC address to IPv6 address binding in its neighbor table/cache. If many hosts reside on the local link, the neighbor table can grow large in size. In IPv6, the interface identifier is 64-bits long. There could be as many as 264 potential number of hosts on the link resulting in potentially 264 neighbor table entries. With IoT devices prevalent these possibilities become close to reality.

A malicious host (Host X) can attempt to fill up the neighbor cache / table of another host or router resulting in a DoS condition.

Step 1: Malicious Host X sends packets to all potential addresses in its local link. The local router R1 will attempt to resolve the IPv6 addresses in order to forward the frames to them. For hosts whose addresses are not yet resolved, R1 will create an incomplete cache entry for a few seconds as it awaits a response that is never received. This entry eventually times out.

However, if Host X sends many such packets fast, it could fill up the R1 neighbor table resulting in a DoS condition.

Control Plane Policing (CoPP)

CoPP is a QoS feature used in security that rate-limits the traffic handled by the route processor (RP). CoPP is a modular QoS CLI (MQC) policy to rate-limit, drop and granularly permit traffic to or from the RP. The RP handles traffic that is categorized into three planes:

• Data plane
• Management plane
• Control plane

The control plane is a collection of processes that run at the process level on the route processor (RP). These processes collectively provide high-level control for most IOS functions. All packets destined for the control plane pass through the central switch engine before they are forwarded to the process level. The control-plane and central switch engine are part of the RP.

Majority of traffic managed by the RP is handled by way of the control and management planes. Such traffic includes;

• Routing protocol updates (IGP, BGP)
• Management traffic such as SNMP, SSH,Telnet, NTP, HTTP(S), etc.
• Traffic destined for a local IP address of the switch/router where the local router or switch is the destination of the traffic.

Control-plane Policing (CoPP) provides rate-limiting and filtering capabilites to control the number of packets that have to be processed by the RP of a router or switch. This helps in reducing the load on a router’s RP at any given point in time. It helps protect the RP from denial-of-service (DoS) attacks, and other flooding attacks, reconnaisance attacks.

In CoPP, it is important to rate-limit traffic on all interfaces destined for the local router. A logical interface exists on all routers called the control plane interface. Rate-limiting packets on this interface applies the rate-limit to all the physical interfaces that need to be processed by the RP. Quality of Service (QoS) and policing on the control plane interface rate-limits packets entering any interface to protect the RP.

Configuring CoPP

To implement CoPP, the following sequence of steps should be followed:

1. Categorize network traffic into classes using Access Control List (ACLs).
2. Create a Class Map (CM) to identify traffic to be policed (rate-limited).
3. Create a Policy Map (PM) to define the action to take on identified traffic by implementing a defined policy.
4. Create a Service Policy which specifies where to apply the policy map

CoPP is hardware-accelerated if the command mls qos is applied.

Categorize Network Traffic using ACLs

CoPP traffic needs to first be identified and grouped into different classes based on importance, function or protocol type.

ACLs are used to identify traffic to be policed. ACLs should be configured for each of the classes categorized in the previous CoPP traffic classification stage. These classes include: BGP, IGP, critical applications, file management, interactive management, monitoring, and default. Each ACL should permit all known protocols in its class. Traffic for the default class should be configured to permit any type of traffic e.g permit ip any any.

Extended ACLs are usually used for classifying traffic as they can be configured to match the traffic port/protocol numbers.

When configuring ACLs for the identified categories, traffic for certain classes such as SNMP, (T)FTP, GRE, is originated from known sources. In such cases, the ACE entries in these ACLs should explicitly define the source IP address. If the ports for these traffic sources is known, then the ACEs should be configured to permit traffic from these specific port numbers as well.

The different traffic categories include:

• BGP: For maintaining BGP operations such as neighbor formation and maintenance, prefix exchange.
  R1(config)#ip access-list extended ACL_COPP_BGP
R1(config-ext-nacl)#remark BGP traffic
R1(config-ext-nacl)#10 permit tcp any eq bgp any gt 1024
R1(config-ext-nacl)#20 permit tcp any gt 1024 any eq bgp established


• IGP: traffic for formation and maintenance of IGP protocols such as EIGRP, OSPF, RIP.
  R1(config)#ip access-list extended ACL_COPP_IGP
R1(config-ext-nacl)#10 permit ospf any host 224.0.0.5
R1(config-ext-nacl)#20 permit ospf any host 224.0.0.6
R1(config-ext-nacl)#30 permit ospf host 224.0.0.5 any
R1(config-ext-nacl)#50 permit eigrp any host 224.0.0.10
R1(config-ext-nacl)#60 permit eigrp host 224.0.0.10 any


• Monitoring and Reporting: traffic for monitoring the switch or router such as ICMP, IP SLA.
  R1(config)#ip access-list extended ACL_COPP_MONITOR
R1(config-ext-nacl)#10 permit icmp any any
R1(config-ext-nacl)#10 permit icmp any any echo
R1(config-ext-nacl)#20 permit icmp any any echo-reply
R1(config-ext-nacl)#30 permit icmp any any unreachable
R1(config-ext-nacl)#40 permit icmp any any port-unreachable


• Interactive Management: traffic that is interactive in nature and is required for routine network operations such as SSH, Telnet, SNMP, NTP, TACACS. This type of traffic is usually low-volume.
  R1(config)#ip access-list extended ACL_COPP_INT_MGMT
R1(config-ext-nacl)#remark Interactive file management
R1(config-ext-nacl)#10 permit tcp host 10.20.2.1 host 10.1.10.1 eq 22
R1(config-ext-nacl)#20 permit udp host 10.1.10.1 host 10.30.5.1 eq 161
R1(config-ext-nacl)#30 permit udp host 10.1.10.1 host 10.30.5.1 eq 162
R1(config-ext-nacl)#50 permit udp host 10.1.10.1 host 10.80.1.1 eq ntp


• File Management: this type of traffic is used for transfer of files Protocols in this category include: TFTP, FTP. This type of traffic is usually high-volume.
  R1(config)#ip access-list ACL_COPP_FILE_MGMT
R1(config-ext-nacl)#10 permit tcp any host 10.1.10.1 eq ftp
R1(config-ext-nacl)#20 permit tcp host 10.1.10.1 eq ftp any
R1(config-ext-nacl)#30 permit tcp any host 10.1.10.1 eq ftp-data established
R1(config-ext-nacl)#40 permit tcp host 10.1.10.1 eq ftp-data any established


• Critical applications: protocols in this category include GRE, HSRP, GLBP, DHCP, IPsec, VRRP, IGMP, multicast traffic.
  R1(config)#ip access-list extended ACL_COPP_CRITICAL_APPLICATIONS
R1(config-ext-nacl)#remark Critical applications
R1(config-ext-nacl)#10 permit udp host 0.0.0.0 host 255.255.255.255 eq bootpc
R1(config-ext-nacl)#20 permit udp host 10.10.1.20 eq bootps any eq bootps
R1(config-ext-nacl)#30 permit ip any host 22.0.0.2


• Undesirable: malicious traffic that should not be allowed to be processed by the RP. Such traffic may be generated by malware. ACLs can be used to deny this traffic.
• Default: traffic that does not fit into any of the above categories. This traffic should be rate-limited until some specific types within this category can be classified and grouped into newer groups or classified under existing(above) mentioned groups.

Create Class Maps to Define Traffic Class

Class map commands contain a name, one or more match commands and instructions on how the match commands will be evaluated:

class-map <match-any | match-all> <class-map-name>
    match <access-group | protocol | ip prec | ip dscp>

A separate class-map should be configured for each of the configured ACLs for each traffic categorization. Class-maps have a default class-map that deals with traffic that is not explicitly defined. A separate class-map should be explicitly configured for the default traffic ACL.

• Instruction: <match-any | match-all>
  • match-any: traffic must match only one of the commands to be classified as part of the traffic class.
  • match-all: traffic must match all the match commands to be part of the traffic class. Care must be taken with match-all keyword as the traffic will have to match all characteristics in all the match commands.
• match:
  • Access-group: reference the access control list defined in match statement. ACL names are case sensitive.
  • Protocol: You can match by protocol instead of ACL; for example to match ARP packets; match protocol arp
  • IP Prec | IP dscp: to match against only ip packet precedence or dscp

R1(config)#class-map match-all CM_COPP_BGP
R1(config-cmap)#match access-group name ACL_COPP_BGP
R1(config)#class-map match-all CM_COPP_CRITICAL_APPLICATIONS
R1(config-cmap)#match access-group name ACL_COPP_CRITICAL_APPLICATIONS
R1(config-cmap)#exit
R1(config)#class-map match-all CM_COPP_FILE_MGMT
R1(config-cmap)#match access-group name ACL_COPP_FILE_MGMT
R1(config-cmap)#exit
R1(config)#class-map match-all CM_COPP_IGP
R1(config-cmap)#match access-group name ACL_COPP_IGP
R1(config-cmap)#class-map match-all CM_COPP_INT_MGMT
R1(config-cmap)#match access-group name ACL_COPP_MGMT
R1(config-cmap)#class-map match-all CM_COPP_MONITOR
R1(config-cmap)#match access-group name ACL_COPP_MONITOR
R1(config-cmap)#class-map match-all CM_COPP_DEFAULT
R1(config-cmap)#match access-group name ACL_COPP_DEFAULT


Verification

R1#show class-map
Class Map match-all CM_COPP_INT_MGMT (id 5)
   Match access-group name  ACL_COPP_MGMT
                              
Class Map match-any class-default (id 0)
   Match any                  
                              
Class Map match-all CM_COPP_FILE_MGMT (id 3)
   Match access-group name  ACL_COPP_FILE_MGMT
                              
Class Map match-all CM_COPP_DEFAULT (id 7)
   Match access-group name  ACL_COPP_DEFAULT
                              
Class Map match-all CM_COPP_MONITOR (id 6)
   Match access-group name  ACL_COPP_MONITOR
                              
Class Map match-all CM_COPP_BGP (id 1)
   Match access-group name  ACL_COPP_BGP
                              
Class Map match-all CM_COPP_IGP (id 4)
   Match access-group name  ACL_COPP_IGP
                              
Class Map match-all CM_COPP_CRITICAL_APPLICATIONS (id 2)
   Match access-group name  ACL_COPP_CRITICAL_APPLICATIONS


Create Policy Maps to Define a Service Policy

Policy maps are used to associate the traffic class (defined with a class map) with one or more policies resulting in a service policy. Its three main elements are; name, traffic class and policy:

• policy-map <service-policy-name>
• class <traffic-class-name>
• police <cir | rate> conform-action <transmit | drop > exceed-action <transmit | drop > violate-action < transmit | drop >

Each class-map should be associated with a policy map that permits all traffic. The policy for each class should be set as conform-action transmit exceed-action transmit.

Some control-plane policing rates along with recommended actions:

Class	Rate(pps)	Rate(bps)	Conform action	Exceed action
BGP	500	4000000	Transmit	Drop
IGP	50	300000	Transmit	Drop
Monitoring and reporting	125	900000	Transmit	Drop
Interactive management	100	500000	Transmit	Drop
File management	500	6000000	Transmit	Drop
Critical applications	125	900000	Transmit	Drop
Undesirable	100	0	Drop	Drop
Default	100	1000000	Transmit	Drop

R1(config)#policy-map PM_COPP
R1(config-pmap)#class CM_COPP_BGP
R1(config-pmap-c-police)#police cir 4000000 bc 4000000 be 4000000 conform-action transmit exceed-action drop
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_IGP
R1(config-pmap-c)#police cir 300000 bc 60000 be 60000 c conform-action transmit exceed-action drop
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_CRITICAL_APPLICATIONS
R1(config-pmap-c)#cir 900000 bc 180000 be 180000 conform-action transmit exceed-action drop
R1(config-pmap-c-police)#
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_MONITOR
R1(config-pmap-c)#police cir 900000 bc 180000 be 180000 conform-action transmit exceed-action drop
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_FILE_MGMT
R1(config-pmap-c)#police cir 6000000 bc 1200000 be 1200000 conform-action transmit exceed-action drop
R1(config-pmap-c-police)#exit
R1(config-pmap)#class CM_COPP_INT_MGMT
R1(config-pmap-c)#police cir 500000 bc 100000 be 100000 conform-action transmit exceed-action drop


Verification

R1#show policy-map
  Policy Map PM_COPP
    Class CM_COPP_IGP
     police cir 300000 bc 60000 be 60000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_INT_MGMT
     police cir 500000 bc 100000 be 100000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_BGP
     police cir 4000000 bc 800000 be 800000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_FILE_MGMT
     police cir 6000000 bc 1200000 be 1200000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_CRITICAL_APPLICATIONS
     police cir 900000 bc 180000 be 180000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_MONITOR
     police cir 90000 bc 18000 be 10800
       conform-action transmit
       exceed-action drop
       violate-action drop
R1#

The policy map configuration will protect a device's RP from being overwhelmed by control-plane traffic. For illustrative purposes, the following CIR rate for ICMP traffic will be made artificially low.

R1#show policy-map
  Policy Map PM_COPP
  !Output omitted for brevity
    Class CM_COPP_MONITOR
     police cir 90000 bc 18000 be 10800
       conform-action transmit
       exceed-action drop
       violate-action drop

R1#

Apply the Policy Map

A policy map can be applied to a single interface or all interfaces. Depending on your security model, you may wish to apply different policy-maps with different rates to all interfaces and other policies to specific interfaces for instance, the interface pointing to the Internet may have a more restrictive policing than that connected to the internal network.

Apply policy map to all interfaces

A router has a single control-plane interface. To apply the policy-map to all interfaces, enter the control-plane configuration mode and apply the policy-map;

R1(config)#control-plane
R1(config-cp)#service-policy input PM_COPP

The input keyword enforces the policy on ingress traffic.

Apply the policy-map to a single interface

To apply the policy-map to a single interface, enter the specific interface and configure the policy map using the service-policy interface command;

R1(config)#interface g0/0
R1(config-if)#service-policy input PM_COPP

Test and Verify Configuration

On a second device (another router or host device such as PC), you can test the control-plane policing by pinging.

R1#show policy-map control-plane
Control Plane
              
  Service-policy input: PM_COPP
              
    Class-map: CM_COPP_IGP (match-all)
      18 packets, 2312 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_IGP
      police:
          cir 300000 bps, bc 60000 bytes, be 60000 bytes
        conformed 18 packets, 2312 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_INT_MGMT (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_MGMT
      police:
          cir 500000 bps, bc 100000 bytes, be 100000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_BGP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_BGP
      police:
          cir 4000000 bps, bc 800000 bytes, be 800000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_FILE_MGMT (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_FILE_MGMT
      police:
          cir 6000000 bps, bc 1200000 bytes, be 1200000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_CRITICAL_APPLICATIONS (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_CRITICAL_APPLICATIONS
      police:
          cir 900000 bps, bc 180000 bytes, be 180000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: CM_COPP_MONITOR (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_MONITOR
      police:
          cir 90000 bps, bc 18000 bytes, be 10800 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        violated 0 packets, 0 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
              
    Class-map: class-default (match-any)
      56 packets, 6556 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any
              
R1#show policy-map
  Policy Map PM_COPP
    Class CM_COPP_IGP
     police cir 300000 bc 60000 be 60000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_INT_MGMT
     police cir 500000 bc 100000 be 100000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_BGP
     police cir 4000000 bc 800000 be 800000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_FILE_MGMT
     police cir 6000000 bc 1200000 be 1200000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_CRITICAL_APPLICATIONS
     police cir 900000 bc 180000 be 180000
       conform-action transmit
       exceed-action drop
       violate-action drop
    Class CM_COPP_MONITOR
     police cir 90000 bc 18000 be 10800
       conform-action transmit
       exceed-action drop
       violate-action drop
              


Pinging from another Host

R2#ping 30.255.1.1 repeat 500 size 1500
Type escape sequence to abort.
Sending 500, 1500-byte ICMP Echos to 30.255.1.1, timeout is 2 seconds:
!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.
!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!
.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!
!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!
!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!
!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!
!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!
!!!!!!.!!!
Success rate is 93 percent (465/500), round-trip min/avg/max = 1/17/48 ms


CoPP rate-limiting can be observed to have taken effect.

R1#show policy-map control-plane
Control Plane  
                
  Service-policy input: PM_COPP
                
    Class-map: CM_COPP_IGP (match-all)
      40 packets, 4380 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_IGP
      police:    
          cir 300000 bps, bc 60000 bytes, be 60000 bytes
        conformed 40 packets, 4380 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_INT_MGMT (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_MGMT
      police:    
          cir 500000 bps, bc 100000 bytes, be 100000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_BGP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_BGP
      police:    
          cir 4000000 bps, bc 800000 bytes, be 800000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_FILE_MGMT (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_FILE_MGMT
      police:    
          cir 6000000 bps, bc 1200000 bytes, be 1200000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_CRITICAL_APPLICATIONS (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_CRITICAL_APPLICATIONS
      police:    
          cir 900000 bps, bc 180000 bytes, be 180000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: CM_COPP_MONITOR (match-all)
      500 packets, 757000 bytes
      5 minute offered rate 11000 bps, drop rate 0000 bps
      Match: access-group name ACL_COPP_MONITOR
      police:    
          cir 90000 bps, bc 18000 bytes, be 10800 bytes
        conformed 465 packets, 704010 bytes; actions:
          transmit
        exceeded 35 packets, 52990 bytes; actions:
          drop  
        violated 0 packets, 0 bytes; actions:
          drop  
        conformed 10000 bps, exceeded 0000 bps, violated 0000 bps
                
    Class-map: class-default (match-any)
      135 packets, 13264 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any
R1#

Troubleshooting Control-Plane Policing

Troubleshooting control plane policing requires troubleshooting of the various components of CoPP i.e., access control lists, class maps, policy maps and service policies. When troubleshooting CoPP, consider;

ACLs

When troubleshooting ACLs for CoPP, focus on the following;

• Verify correct source and destination addresses, protocols, port number, action (permit | deny): show access-list
• Grouping: if grouping traffic types, ensure that they are grouped based on function; e.g. routing protocols (BGP, OSPF, EIGRP), management protocols (SSH, TELNET, HTTP(S), TFTP, SNMP, DNS, NTP).
• Action: with CoPP, a permit action in an ACL means match the traffic and apply the policy. Deny means exclude the traffic from the class and move on to the next class.
• Protocol: If the wrong protocol is specified in the ACL, the wrong type of traffic will be matched.
• Source and destination: the correct source and destination ACLs should be applied. During troubleshooting, change IP address to any to see the effect.
• Operators and Ports: Ensure correct ACL operator and port numbers are defined.
• Avoid log and log-input ACL keywords for CoPP due to unexpected results in CoPP functionality.

Class Maps

• Watch-out for the match-all and match-any commands.
• Verify that the class-map is configured correctly show class-map. Verify correct instructions (match-any, match-all), correct ACL, protocol,IP prec, DSCP.

Policy Maps

When troubleshooting policy maps, consider;

• Verify that the service policy is applied in the correct direction: show policy-map control-plane.
• Verify that the policy-map is correctly configured; show policy-map
• Check the correct class-map, rate or CIR, conform-action, exceed-action,correct order.
• Order of operations: classes defined are processed from top to down.
• Class-map: has the correct class-map been configured correctly.
• Policy: Ensure the correct CIR in bps and rate in pps have been configured. In some IOS versions, if traffic that matches a class is to be dropped, replace police command with drop keyword.
• Default-class: if traffic does not match any defined class, it will be subjected to conditions laid out in the default class.
• Case: class names are case sensitive.

Service Policy

When troubleshooting the application of a service policy;

• Correct interface: service policy can be applied only to one interface, the control-plane. If applying to a physical interface, ensure that the service policy is configured on the correct interface. Confirm with show policy-map interface <interface-name>
• Direction: input for incoming packets. Confirm direction with; show policy-map control-plane. Not all IOS versions support output. For routing protocols, output CoPP would be for replies to queries / requests or ACKs. For ICMP; error or informational reply, for telnet, SSH, HTTP, SNMP replies or traps. Ensure the ACL and class-map are configured appropriately for replies.
• Case: Policy maps are case-sensitive; verify with show policy-map control-plane
.