CoPP & uRPF Practice Questions

Answers and explanations appear when you work through the set above.

1. What is the correct high-level order of components used to build a CoPP policy?

   • Policy-map first, then class-map referencing it, then classification ACLs added last
   • Classification ACLs to match specific traffic types, class-maps that reference those ACLs, a policy-map applying actions (such as police) per class, then service-policy applied to the control-plane interface
   • A single access-list applied directly with control-plane access-group
   • A route-map matching AS-path, then applied under control-plane

2. Which configuration mode and command actually attach a completed CoPP policy-map so it takes effect?

   • Interface configuration mode, using service-policy input
   • Control-plane configuration mode, using service-policy input (or output) <policy-map-name>
   • Global configuration mode, using control-plane policy <policy-map-name>
   • Line configuration mode under the VTY lines

3. A CoPP classification ACL for the routing-protocols class is written to permit only OSPF and EIGRP multicast/unicast traffic, but the engineer forgets to include a permit statement for BGP TCP/179 sessions to configured peers. What happens to BGP control traffic?

   • BGP is automatically exempted from CoPP regardless of ACL content
   • BGP packets fail to match the routing-protocols class ACL and fall through to whatever class (often a default or lower class-default policing rate) does match, potentially getting dropped or excessively rate-limited if that class's rate is too low for legitimate BGP traffic
   • BGP traffic is entirely blocked from reaching the CPU because it is not classified as a control-plane protocol
   • The router automatically adds BGP to the ACL the first time a peer is configured

4. Which command shows per-class matched packet/byte counts and any drops caused by an applied CoPP policy?

   • show ip protocols
   • show policy-map control-plane
   • show access-lists compiled
   • show processes cpu

5. In a properly designed CoPP policy, what should the class-default class typically do with unclassified traffic reaching the control plane, and why?

   • Permit it at line rate with no policing, since class-default is meant to be unrestricted
   • Police it to a conservative rate (rather than dropping it outright in most designs) so unexpected but potentially legitimate control-plane traffic is still rate-limited rather than either flooding the CPU or being silently blackholed entirely
   • Deny all traffic in class-default unconditionally
   • class-default is ignored by CoPP and only applies to interface QoS

6. OSPF adjacencies begin randomly flapping shortly after a new CoPP policy is deployed, and show policy-map control-plane shows drops accumulating in the class carrying OSPF traffic. What is the most likely cause?

   • The OSPF hello/dead timers were changed at the same time
   • The police rate configured for the class matching OSPF traffic is set too low for the actual volume/burst of OSPF control traffic, causing legitimate hello or LSA packets to be dropped
   • CoPP only affects data-plane traffic and cannot cause this symptom
   • The classification ACL is missing a deny statement for OSPF

7. What is the recommended troubleshooting order when CoPP is suspected of dropping legitimate management or routing-protocol traffic?

   • Immediately remove the CoPP policy from the control-plane before investigating anything else
   • Verify the symptom against show policy-map control-plane counters to confirm drops are actually occurring in a specific class, identify which classification ACL that traffic should match, confirm the ACL correctly matches it, then evaluate whether the policer rate/burst for that class is adequate
   • Reboot the router to clear the CoPP counters and see if the problem recurs
   • Rewrite the entire CoPP policy from scratch without reviewing the existing one

8. Why is CoPP generally considered a control-plane and management-plane protection, distinct from a standard interface access list applied to transit traffic?

   • They are functionally identical and either one can be used interchangeably
   • CoPP only affects traffic destined to or sourced from the route processor itself, while an interface ACL filters traffic passing through that specific interface regardless of whether it is destined to the router; transit traffic switched entirely in hardware is unaffected by CoPP
   • CoPP is applied per-VLAN while ACLs are applied per-interface
   • CoPP replaces the need for any interface ACLs

9. An engineer creates a well-designed CoPP policy-map with distinct classes and rates, but forgets the final activation step. What is the practical effect on the router?

   • The policy-map partially applies automatically as soon as it is created
   • No CoPP protection is active at all, since a policy-map has no effect until it is applied with service-policy under control-plane configuration mode
   • IOS applies a default CoPP policy automatically as a placeholder
   • The policy-map applies only to the console line

10. What does Unicast Reverse Path Forwarding (uRPF) use to decide whether to accept or drop an incoming packet?

    • The destination address, checked against the local routing table
    • The source address of the incoming packet, checked against the router's forwarding information base (FIB) to determine if a route to that source exists (and in strict mode, whether it points back out the interface the packet arrived on)
    • The TTL value in the IP header
    • The DSCP marking in the packet

11. How does uRPF strict mode differ from loose mode in its acceptance criteria?

    • Strict mode only checks that any route to the source exists; loose mode requires the route to point out the receiving interface
    • Strict mode requires the best route back to the source address to point out the exact interface on which the packet was received; loose mode only requires that some route to the source address exists in the FIB, regardless of which interface it points to
    • Strict mode is used only on point-to-point interfaces and loose mode only on multi-access interfaces
    • There is no functional difference; loose is simply the deprecated name for strict mode

12. A branch router has two active WAN uplinks and legitimately receives return traffic on a different interface than the one packets from that source would be sent out on, due to asymmetric routing between two ISPs. Strict uRPF has been enabled on both uplinks and is dropping large amounts of legitimate traffic. What is the appropriate fix?

    • Switch to loose mode uRPF, which tolerates asymmetric paths since it does not require the reverse path to match the ingress interface
    • Increase the uRPF ACL's permit statements to cover every possible source
    • Enable strict uRPF on the LAN interface instead to compensate
    • There is no fix; strict uRPF and asymmetric routing are fundamentally incompatible and one of the uplinks must be removed

13. A default route (0.0.0.0/0) exists in the FIB pointing out an interface where loose mode uRPF is enabled. What effect does this default route have on uRPF's source validation?

    • The default route is ignored by uRPF and has no bearing on the check
    • Without the allow-default keyword, a source reachable only through the default route fails the uRPF check; allow-default must be configured if the default route is to satisfy validation
    • A default route always causes uRPF to fail closed and drop all traffic
    • Default routes only affect strict mode, not loose mode

14. Which command enables strict-mode uRPF on an interface?

    • ip verify unicast source reachable-via rx
    • ip verify unicast source reachable-via any
    • ip verify unicast reverse-path strict
    • ip source-guard strict

15. Which command enables loose-mode uRPF on an interface?

    • ip verify unicast source reachable-via rx
    • ip verify unicast source reachable-via any
    • ip verify unicast reverse-path loose
    • ip antispoof loose

16. What is a key operational dependency of uRPF that makes it sensitive to routing changes and CEF status?

    • uRPF has no dependency on the routing table and works purely off static ACLs
    • uRPF relies on Cisco Express Forwarding (CEF) and the current FIB contents; since the FIB mirrors the routing table in near real time, any routing change (a link flap, route withdrawal, asymmetric path shift) immediately changes what uRPF will accept or drop
    • uRPF only reads a snapshot of the routing table taken at interface configuration time and requires a reload to update
    • uRPF depends on NetFlow being enabled on the same interface

17. Which command displays per-interface uRPF drop counters to help confirm whether uRPF is actively discarding packets?

    • show ip cef summary
    • show ip interface <interface> (which includes a uRPF section with verification drop counts when uRPF is enabled)
    • show ip route summary
    • show access-lists dynamic

18. A troubleshooting ticket reports intermittent packet loss for a customer whose traffic legitimately arrives via a backup path during a primary link outage, and the loss coincides with when uRPF strict mode is enabled on customer-facing interfaces. What order of investigation correctly isolates uRPF as the cause versus a routing problem?

    • Assume it is a routing problem and adjust metrics without checking uRPF drop counters at all
    • Check whether the routing/FIB path for the customer's source actually points out the interface where their traffic is arriving; if it does not (because of the backup path), correlate that with show ip interface uRPF drop counters incrementing on that interface, confirming strict uRPF is dropping asymmetrically routed return traffic rather than a pure routing fault
    • Disable CEF to rule out a forwarding-plane issue first
    • Clear the interface counters and wait 24 hours before doing any further checks

19. In what general network position is strict-mode uRPF most appropriate, versus loose mode?

    • Strict mode is best on multihomed core routers with asymmetric paths; loose mode is best on single-homed stub/edge links
    • Strict mode is best suited to single-homed edge or access links where traffic is known to be symmetric (such as a customer stub network with one uplink), while loose mode suits multihomed or asymmetric-routing environments where strict mode would drop legitimate traffic
    • Both modes are equivalent in every deployment scenario and the choice is arbitrary
    • Strict mode should only ever be used on internal LAN interfaces, never on WAN-facing interfaces