Management Plane Security

 SSH

Step 1: Configuration of the hostname is one of the critical elements used to create an RSA key pair.

#hostname name

Step 2: Domain name is one of the elements used to create a key pair.

#ip domain-name domain-name

Step 3: Create local user names, privilege and password;

#username name privilege level secret password

Step 4: Generate RSA Key pair;

#crypto key generate rsa modulus size

Step 5: To enable remote SSH login on VTY terminals;

#line vty 0 4

#transport input ssh

Step 6: Enable authentication on the vty lines;

#login local

Enable

Enable secret gives level 15 privileges on an IOS device configured with #enable secret password.

Enable secret password appears in a router’s running configuration as a SHA-256 has. (4 in the string). Older IOS versions use MD5 (5 in hash).

Line

Line password authenticates a user logging to VTY, console or AUX. It shows up as clear text in running configuration. Encrypt the password using #service password encryption. This uses Type 7 encryption (Vigenere cipher). Cisco recommends the use of username password combination.

OSPF Optimization

 Accelerating OSPF Convergence

Can be done through faster Hellos and BFD (Bi-Directional Forwarding), and segmentation using areas. Use of areas reduces the SPF calculations

Faster Hello Packets

Default timers: 10 seconds, dead-interval; 40 seconds. OSPF should not be used for failure detection. Most lower layer protocols are faster at failure detection. OSPF default timers are often slow. Designers often alter these timers to effect faster converge and faster failure detection. Decreasing default timers will increase network traffic and packet processing demand on the hardware. In Cisco, to implement a one second hold interval with a hello-multiplier e.g. five minutes, send a hello packet every 200 milliseconds.

Bi-Directional Forwarding

BFD is an alternative to fast Hellos. It is not specific to OSPF. It provides a light-weight failure detection and is processed by the line card and not by the CPU. It primarily operates at the data-plane rather than the control-plane. BFD relies on the routing protocol neighborship establishment process to begin working. It doesnot help to lower the time it takes to establish a neighborship.

BFD operates in two modes; asynchronous and demand.

BFD Asynchronous

Systems exchange control packets. If the receipt of these packets stops, the session is dropped and the protocol that is configured with it is notified for example OSPF.

BFD Demand Mode

BFD assumes that another mechanism is being used to verify connectivity. Generally, asynchronous mode is used in normal production.

BFD Echo Function

The Echo function is used is any mode. Using the Echo function, a device is configured to send control packets towards a remote system with the expectation of having them loopback. This verifies the path to the remote system as well as the forwarding path of the remote system. BFD sessions can be configured independently in both directions.

Controlling OSPF LSA Generation and Propagation

Technologies include;

• LSA Throttling

• LSA Flood Pacing

• LSA Group Pacing

• LSA Retransmission Pacing

LSA Throttling

Limits the regeneration of repeat LSA updates for the same LSA when the topology changes. The ‘same’ LSA refers to common LSA ID, LSA Type, Advertising Router ID.

Normal LSA Update Behaviour

Initial LSA update is sent immediately and then rate-limited and cannot be resent for another five seconds. As updates come in, the message that is going to be sent may be modified but is not sent until the rate limit timer expires. A similar condition happens on received updates from a neighbor. By default, an update is only accepted if it is inter-leaved by at least one second. If it is not, the packet is dropped.

Waiting for the five seconds to expire during the intialization of OSPF and times of network change can sow the propagation of LSAs. OSPF throttling feature can be used to combat this. LSA throttling alters how OSPF handles the generation of OSPF update packets. You can do this through the configuration of three different parameters;

• LSA start-interval

• LSA hold-interval

• LSA max-interval

The initial transmission of an update packet is always sent immediately it is generated. Pending no other features are configured, the generation of the second update packet is governed by the LSA start-interval. If an event occurs and the OSPF device needs to send an additional update packet, it waits until the start-interval expires. At this point, the LSA hold-interval begins. If an event occurs during this hold-interval, the device waits to send the update packet until that interval expires. If an update is required during the hold-interval, the next hold interval doubles. The hold-interval never exceeds the max-interval.

LSA Hold/Max Interval

The max-interval is used as an update packet ceiling in controlling how long the hold-interval could eventually become. This doubling happens every time an additional event occurs within the current hold-interval. When the max-interval is reached, then it is used as the hold-interval to delay LSA update packet generation until it expires. This remains true until no events occur within two hold-intervals or max-intervals depending on the situation. At this point, the process repeats and the start-interval is used if an event occurs.

LSA throttling is a good way to increase convergence times and slow down LSA update generation during instability.

OSPF Update Packet Pacing

Affects the generation of remote OSPF packets. Three different OSPF timers can be modified including; flooding pacing, re-transmission pacing and group pacing.

Flood Pacing

Allows you to control the packet spacing between consecutive update packets in the OSPF transmission queue. On Cisco, by default, if multiple packets exist in the transmission queue, they are sent every 33ms.

Retransmission Pacing

Simlar to flooding pacing but it affects the retransmisison queue. By default, if multiple packets exist in the retransmission queue, they are sent every 66ms.

Group Pacing

Controls how LSAs are refreshed by an OSPF device. Typical LSA refresh rate is 30 minutes. An LSA is refreshed when is age reaches 30 minutes. If each individual LSA works on its own independent timer, then packets would be retransmitted all the time especially in large networks. Group pacing allows LSAs that are expiring within the same general time to be sent simultaneously. By default, it is set to 240 seconds. LSAs expiring in 240 second interfval are held and sent at the same time. This provides efficiency and lowers demand on the network. Pacing timers generally work well and it is advised that they should not be modified. Any modification should be done after thorough testing.

Altering SPF Behaviour

SPF behavior can be altered through SFP throttling and incremental SPF.

SPF throttling operates similarly to LSA throttling. It provides a way to control when SPF is run after an event occurs. SPF uses three parameters; SPF start-interval, SPF hold-interval, SPF max-interval.

SPF Throttling

When an event initially occurs, the start-interval begins. On expiry, SPF is run using the new information and hold-interval begins counting down. If any new event occurs during this hold-interval, then the SPF process is run once it expires and a new hold interval begins but with twice the configured hold interval time (events occurring during the hold-interval waits until expiry). New hold-interval begins with twice the duration). If no event occurs within two hold-intervals, then the process resets and again is governed by the start-interval. The process of doubling the hold-interval when additional events occur continues until the hold interval time reaches the max-interval. Multiple intervals result in hold-interval equalling max-interval. The max-interval acts as a timer ceiling. Once reached, SPF runs every max-interval as long as additional events continue to occur. If events are not received within two max-intervals trigger process reset. Cisco defaults to five second start-interval and ten second hold and max-intervals.

Incremental SPF (iSPF)

ISPF changes how and when SPF is run. LSA Type 1 and 2 changes force SPF to run. Often this isn’t required as the SPT will now change for every device resulting in many nodes needlessly running SPF. ISPF makes the running of SPF conditional based on three conditions;

• Whether a new leaf-node is being added or removed

• Whether a change affects the SPT of a device.

• Whether a change affects a limited part of the SPT.

Addition of a leaf-node does not affect SPT of existing devices hence a full SPF run is unneeded. ISPF prevents a full SPF run on non-local devices. It limits the SPF run on nodes directly associated with the changes. This includes devices where the addtion or removal will not locally modify connectivity.

Failure of a link that is not part of the SPT of a device: iSPF limits SPF run to only affected entries.

Link that is part of SPT Fails but does not affect all SPF devices: iSPF limits the devices that run SPF to those directly affected by the link failure. Only devices that are downstream from a failure will re-run SPF. Use of iSPF should be assessed based on environment.

Reducing the Size of the Link-State Database

To reduce the size of the LSDB implement the following;

• Stub areas

• LSA summarization

• LSA Type 3 filtering

• Prefix suppression

• OSPF network types

Stub Areas

Limits the type of allowed LSAs

Most often used with single exit areas.

LSA Summarization

Different types of summarization include area summarization and external summarization.

Area Summarization

Used on ABRs controls how inter-area routes are generated and advertised into an area. Before summarization, routes are advertised with their original mask information. Only intra-area routes are summarised. An ABR must be part of the area where the targeted entries are sourced from. If they are not, it will not see the routes as intra-area and will not summarize them. The metric used for the summary route is based on the lowest existing metric. If this is not desired, configure a static metric.

Area summarization limits the advertisements that are known by devices in other areas (limits inter-area database entries). It provides protection from devices needing to make topology changes as they occur in other areas.

External Summarization

Summarizes external routing information (redistributed routes). During redistribution, limit the number of individual routes being inserted. Summarization is performed on the ASBR. Unstructured (discontiguous) summarization causes problems with route summary configuration. Summarization may introduce inefficient routing in areas with multiple ABRs.

Type 3 LSA Filtering

Controls Type 3 LSAs being advertised into or from an area. Provides granular control over advertisements into different areas. Ensure verification before using in production. Always verify behaviour when using multiple features.

Prefix Suppression

Allows suppression of advertisements of connected prefixes and can be implemented globally or at the inteface.

• Prefix Suppression Globally: all connected prefixes that are not on loopbacks, passive interfaces or secondary interfaces are suppressed. Individual interfaces can have prefix suppression disabled to allow their addresses to be advertised.

• Prefix Suppression Locally: all addresses are suppresssed including secondary addresses.

Prefix suppression is very handy on large networks to reduce the size of the LSDB. However, it can complicate troubleshooting.

OSPF Network Types

Some OSPF network types utilize additional LSAs than others. It is agood idea to assess whether the default options are the best. Ethernet is multi-access and OSPF defaults to broadcast network type requiring Type 2 LSA. It also requires a master/slave election causing a little delay in the neighborship formation process. If an Ethernet interface connects to another OSPF peer device, better to configure the interface as point to point network type. Here, the designated router (DR) is not required and Type 1 LSAs only are used.

Reducing the Effects of Restarts on OSPF

Graceful restart is covered in RFC 3623. it allows the restarting of a device without affecting the forwarding of traffic. This will require tweaks to normal OSPF operation. Device restart methods include; using power switch (hard) and using software (soft).

• Hard Restart: all adjacencies are dropped. This type is generally not recommended.

• Soft Restart: OSPF notifies peers of an impending restart by flushing all LSAs and sends empty Hello packets resulting in the dropping of all neighborships. Neighbors know immediately that a peer is going to become unavailable and make appropriate adjustments to their LSDB and routing.

Regardless of restart method, traffic flow is interrupted through re-routing or black-holing). Some platforms handle data-plane functions on the line-cards and control-plane and management functions by CPU.

With graceful restart, devices must separate data and control-plane functions. The devices must modify OSPF behaviour when a restart occurs. OSPF normally notifies peers of impending restrat by advertising LSAs originated by the device with a max LSA age. This brings down neighborships causing peers to run SPF to re-route traffic. Normal OSPF behaviour affects traffic. In graceful restart, devices alert peers of a restart. Neighbors lock the neighborship (assuming this feature is supported) maintaining the appearance of a full adjacency. Neighbors continue to send traffic to the device as normal. They, however, do not receive normal OSPF messages. The restarting device uses a graceful LSA to communicate with its neighbors. This is sent on all OSPF interfces with a link-local scope triggering neighbors to prepare for a restart. This LSA includes an expected grace period which is the duration of the assumed full neighborship.

Grace LSA

Are sent continually until they are acknowledged. If not acknowledged, normal restart commences (no graceful restart). The restarting device does not originate or flush LSAs and continues to use its pre-start routing tables until all neighborships return to normal operation. Neighborship establishment, after graceful restart, is the same as normal restart. The data path through the device remains uninterrupted. Grace LSAs are flushed by, restarting device, once neighborships are re-established runs through the normal OSPF process and re-originates its LSAs.

Graceful Restart Modes

Graceful restart defines two modes of operation; one for the restarting device and another for helper peer devices. The mode for peers is referred to as helper mode. Many more devices support helper mode than graceful restart mode. On Cisco, graceful restart is referred to as NSF (Non-Stop Forwarding). Full support is referred to as NSF capable. Helper support is referred to as NSF-aware.

Cisco: Troubleshooting EIGRP

 To verify layer 3 reachability, use the ping command.

To view EIGRP peers/neighbors and the interfaces that they are reachable through;

#show ip eigrp topology

#debug eigrp packets <terse>

watch out for stub configurations, passive interfaces, K-value mismatches summarization (IPv4, IPv6)

EIGRP issues are usually;

• Neighbor adjacency issues

• Routing issues

Neighbor Issues

• Are interfaces operational

• Does EIGRP AS match

• Are interfaces enabled for EIGRP

• Is there an interface that is configured as passive?

• Authentication

• Interface is down: The interface must be up/up.

• Mismatched autonomous system numbers: Both routers need to be using the same autonomous system number.

• Incorrect network statement: The network statement must identify the IP address of the interface you want to include in the EIGRP process.

• Mismatched K values: Both routers must be using exactly the same K values.

• Passive interface: The passive interface feature suppresses the sending and receiving of hello packets while still allowing the interface’s network to be advertised.

• Different subnets: The exchange of hello packets must be done on the same subnet; if it isn’t, the hello packets are ignored.

• Authentication: If authentication is being used, the key ID and key string must match, and the key must be valid (if valid times have been configured).

• ACLs: An access control list (ACL) may be denying packets to the EIGRP multicast address 224.0.0.10.

• Timers: Timers do not have to match; however, if they are not configured correctly, neighbor adjacencies could flap.

Verification of Neighbor Issues

#show ip eigrp neighbors <detail>

To identify whether the physical and data-link layers are operational;

#show ip interface brief

#show ip eigrp interface <detail>

• AS: the AS specified in the router command

• Interface: the interfaces over which EIGRP is configured

• Peers: number of directly connected EIGRP neighbors on the interface

• Xmit: Queue Unreliable and Reliable: The number of packets remaining in the unreliable and reliable queues

• Mean SRTT: the average Smooth Round Trip Time (SRTT) interval in milliseconds, for all neighbors on the interface.

• Pacing Time Unreliable and Reliable: number of milliseconds to wait after transmitting unreliable and reliable packets.

• Multicast Flow Timers: number of milliseconds to wait for an acknowledgement of a multicast packet by all the neighbors before transmitting the next multicast packet.

• Pending Routes: number of routes in the packets in the transmit queue that are waiting to be sent.

#show ip protocols

Routing Issues

• Are networks being advertised?

• Is ACL blocking advertisements?

• Is there a discontiguous network issue?

• Redistribution

• Summarization

• Bad or missing network command: The network command enables the EIGRP process on an interface and injects the prefix of the network the interface is part of into the EIGRP process.

• Better source of information: If exactly the same network prefix is learned from a more reliable source, it is used instead of the EIGRP learned information.

• Route filtering: A filter might be preventing a network prefix from being advertised or learned.

• Stub configuration: If the wrong setting is chosen during the stub router configuration, or if the wrong router is chosen as the stub router, it might prevent a network prefix from being advertised.

• Interface is shut down: The EIGRP-enabled interface must be up/up for the network associated with the interface to be advertised.

• Split horizon: Split horizon is a loop-prevention feature that prevents a router from advertising routes out the same interface on which they were learned.

Verification of Routing Issues

#show ip interface brief

#show ip route eigrp

#show ip protocols

#show access-list

Troubleshooting Stub

#show ip protocols

#show ip eigrp neighbor detail

Troubleshooting Summarization

Discontiguous Subnets

Poorly summarized supernets; show ip route

Summarization requires at least one subnet in the RIB for summary to be advertised.

Cisco: Optimising EIGRP

 The two main EIGRP optimization techniques are route summarization and stub routing.

Stub configurations limit query scope. Support for Unequal Cost Load Balancing also provides optimization.

EIGRP Queries

When a router loses a route and doesn’t have a feasible successor in its topology table, it searches for an alternative path to the destination. This condition is known as going active on a route. Queries are send when a route is lost and no feasible successor is available. Queries are sent to all neighboring routers on all enabled interfaces except the interface of the successor. If neighbors have the lost route information, the stop the query from spreading otherwise queries are further propagated.

Active routes can be viewed in the topology command #show ip eigrp topology

Query exchange can be optimized using EIGRP stub routing and route summarization.

EIGRP Stub Routers

One way to reduce the number of EIGRP queries and improve network scaling is to mark the spokes of a large network as stubs. EIGRP stub routing;

• improves networking stability

• reduces resource utilisation

• simplifies remote router configuration

EIGRP Stub options enable you to precisely specify which routes the EIGRP stub should advertise;

• Connected: advertises connected routes that are included with a network command.

• Summary: advertises configured summary routes

• Static: advertises static routes if redistribute static command is configured.

• Redistribute: advertises redistributed routes if redistribution is configured.

• Receive-only: prevents the stub from sending any type of route.

Stub configuration defaults are connected and summary. You can combine all stub options except for receive-only to achieve the desired result. Receive-only option can be used in only two scenarios;

• when the router has a single interface

• if NAT with PAT is configured so that all hosts are hidden behind a single WAN interface.

Configuration

Classic mode

#router eigrp 10

#eigrp stub

To verify stub status on a neighboring router;

#show ip eigrp neighbor detail

EIGRP Stuck in Active

Failure to receive a response to a query message can lead a session termination. A router must receive replies to all queries sent and before a new path is calculated. If any reply is lost or missing;

• the route enteres Stuck-in-active state

• neighbor status is verified; if no response is received, the neighbor relationship is reset.

SIA messages are level 3 messages.

When no reply to a query is received, EIGRP sends an SIA query when the active timer is halfway through (90 seconds). This enables the neighboring router to respond with an SIA-Reply and confirm to the upstream router that is still searching for a replacement route.

EIGRP Summary Routes

Summarization limits query scope and improves convergence. If a router receives an EIGRP query for a prefix which is described in the routing table by a summary route, it immediately responds with a reply. Summarization is implemented on the interface in classic mode. In named mode, it is implemented in the address-family interface mode. The summary masks can be in dotted decimal format or prefix notation.

CAUTION: if a more specific route is in the RIB, it is always preferred regardless of the metric. For alternate paths, ensure that the summary address is configured on all the interfaces otherwise, the more specific routes will only be suppressed on the interface on which the summary address is configured.

A null route is automatically created in the RIB after configuring a summary route. The lowest metric of any of the routes within the summary route is used as the metric for the summary route.

Default Route

To redistribute a default route in EIGRP;

• redistribute a static default router. To inject a default route and not every static route;

  Step 1: create an ACL to identify the default route #permit 0.0.0.0 0.0.0.0
  Step 2: define a route-map and reference the ACL from Step 1. #match ip addresss ACL_DEFAULT

  Step 3: Redistribute the static route; in named mode # topology base #redistribute static route-map RM_DEFAULT.

  The redistributed default route will have an AD of 170 with a code D EX. Usually, when redistributing into EIGRP, a seed metric must be specified. This is because EIGRP needs to know all the metric components of a route i.e. bandwidth, delay, reliability, load, MTU, hop count. In the case of static and connected routes, EIGRP takes these values from the outgoing interface associated with the route.

• default network command.

When configuring summarization, ensure that the routes exist in the routing table.

EIGRP Load Balancing

EIGRP can distribute traffic over multiple links leading to the same destination to increase the effective network bandwidth. It supports load-balancing over equal metric and unequal-metric paths. Load balancing refers to the distribution of traffic over multiple paths. ECMP is enabled by default across four paths.

Note: Hardware-implemented load-balancing and IP CEF load-balancing may override EIGRP implemented load-balancing.

When network traffic is process switched (by CPU), load-balancing over ECMP occurs on a per packet basis. If fast-switching is being implemented, (data-plane), load-balancing over ECMP occurs on a per destination basis. This behaviour due to CEF characteristics. One some platforms, CEF, allows for configuration on a per packet or per destination load-balancing. Both are enabled by default. To enable Unequal cost load-balancing, use the EIGRP topology base command #variance <1 – 128>. it is disabled by default (one) ECMP.

Variance causes the router to include routes with a metric in a specific range.

Note: variance is applied only after the feasibility condition check is completed;

• Only paths that pass the feasibility condition have the variance multiplier applied to their metric

• to add a feasible successor to the RIB, the metric of the path must be less than the FD of the successor X the variance multiplier.

EIGRP Authentication

EIGRP authentication uses preshared-keys and is configured in interface configuration mode. MD5 is supported by classic and named mode. HMAC-SHA 256 is supported only by named mode. To configure EIGRP classic mode authentication;

Step 1: configure the key chain;

#key chain R1CHAIN

#key 1

#key-string firstkey

Step 2: Configure the authentication mode for EIGRP;

#interface ethernet 0/0

#ip authentication mode eigrp 110 md5

Step 3: Enable authentication to use the key chain.

#ip authentication key-chain eigrp 110 R1CHAIN

The key ID and keys string need to match on all EIGRP peers. In named configuration mode;

#af-interface ethernet 0/0

#authentication key-chain R1CHAIN

#authentication mode md5

In named mode, to configure SHA hashing, use the interface command;

# authentication mode hmac-sha-256 password

Dual stack load-balancing can be enabled with load-balancing supported on both IP or IPv6 or enabled on one and disabled on the other.

Load Balancing

If similar load-balancing configuration is not implemented in EIGRP peers, local routing may implement load-balancing across more links but return traffic utilises a single link resulting in asynchronous routing. Some security mechanisms may e.g. uRPF may block such traffic. Ensure same variance multiplier is used in remote router as well as maximum-path command.

In IPv6 load-balancing, the #show ipv6 route will display only the metric of the best route. To view other unequal routes, view EIGRP topology table.

Authentication

Key ID and key string must match. Verify with #show key chain.

Authentication type (MD5 or SHA256), key ID, key sequence and Digest (of Key ID and key string) is sent in the packet header under authentication (type) section.

To confirm that authentication is running on an interface;

#show ip eigrp interface detail

If configuring keyrings with accept and send lifetimes ensure that;

• The clocks of the routers are synchronized with an NTP server or are similar timestamps

• Provide for some overlap in times of key change so that during the changing of authentication using one key, the second key becomes active by several minutes before the first key becomes invalid.

If two keys are valid at the sametime (overlap in accept/send timestamps), the first valid key in the list will be used e.g. key ID 1 is used instead of key ID 2. The default starttime and earliest acceptable date is 1^st January, 1993.

Verification, in named mode, of authentication is #show eigrp address-family ipv6 interfaces detail ethernet1/2.

For hmac-sha-256, there’s no need for a key chain.

Control Plane Policing (CoPP)

Overview of 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 over 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 i.e., 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.

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

Traffic to be rate-limited needs to first be identified and categorized into different classes based on importance, function or protocol type.

ACLs are used to identify and classify traffic to be rate-limited. These classes include:

• BGP
• IGP
• Critical applications
• File management
• Interactive management
• Monitoring
• Default

A separate ACL should be configured for each of these traffic categories. Each ACL should permit all known protocols in its class. Traffic for the default class should be configured to permit any other 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.

During categorization of traffic, it is important to note that 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. BGP uses TCP port source port 179; when configuring ACE entries, the BGP port number or keyword bgp are valid high-level protocols for matching against.
  R1(config)#ip access-list extended ACL_COPP_BGP
R1(config-ext-nacl)#remark BGP traffic
R1(config-ext-nacl)#10 permit tcp any gt 1024 any eq bgp
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. OSPF uses IP protocol number 89 and IPv4 multicast addresses 224.0.0.5 and 224.0.0.6 or IPv6 multicast address FF02::5 and FF02::6. EIGRP uses IP protocol number 88 and IPv4 multicast address 224.0.0.10 IPv6 multicast address FF02::A. The IP protocols can also be matched using the keywords eigrp or ospf.
  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 to transfer 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


  bootpc and bootps are the keywords for DHCP.

• Undesirable: malicious traffic that should not be allowed to be processed by the RP. Such traffic may be generated by malware. The port numbers, transport protocol used etc of malware can only be known if the malware has has been profiled .
• 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) listed groups.

Create Class Maps to Define Traffic Class

Class maps are used to define classes of the traffic to be rate-limited. A class map may reference an ACL, protocol, IP Prec or IP DSCP values in a packet.

A separate class-map should be created for each of the configured ACLs for each traffic category. 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.

1. Define the class map name: using the command class-map <match-any | match-all> <class-map-name>. The matching instruction is match-any or 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.
2. Specify how the traffic will be matched: using the command match [access-group [<acl-number> | name <acl>] | protocol | ip prec | ip dscp]
   • Access-group: reference the previously configured access control list 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 an IP packet's Precedence or DSCP fields

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 define the rate-limit parameters of the classified traffic. Policy maps are used to associate the traffic class (defined with a class map) with one or more policies resulting in a service policy. To configure a policy map:

1. Define the policy map name: using the command policy-map <service-policy-name>
2. Reference a configured class map: using the command class <traffic-class-name>
3. Define the rate-limit threshold and action: at which traffic will be rate-limited, and action to take for conformal traffic, and rate-limit violation using the command 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
.