350-401 · topic practice
Practise 350-401 ACL questions covering standard vs extended ACLs, top-down processing, implicit deny, inbound vs outbound placement, and troubleshooting traffic that is unexpectedly blocked or permitted.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
What the exam tests
ACL questions usually test top-down rule processing, source and destination matching, protocol or port logic, and where the ACL should be applied.
Why learners struggle
ACL questions are missed when learners apply the wrong direction, overlook the implicit deny, or confuse standard ACL source-only matching with extended ACL protocol and destination matching. A single out-of-order rule or wrong interface direction makes an otherwise correct ACL fail.
Watch out for
Practice set
20 questions · select your answer, then reveal the explanation
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
Trap 1: The routers have a different IOS version that interprets 'outbound'…
The direction parameter is validated by the Ansible module itself, not by the router's IOS. The `ios_acl_interfaces` module only accepts the exact string values `in` or `out` for `direction`, so passing `outbound` would either cause a validation error or be ignored/defaulted; it cannot be reinterpreted by the device. Different IOS versions do not change how the module handles the parameter because the module runs on the control node and translates the validated value into the correct CLI command. Thus, the router's IOS version is irrelevant to the symptom.
Trap 2: The engineer forgot to include the 'state: present' parameter, so…
In Ansible's `ios_acl_interfaces`, `state: present` is the default behavior, so omitting it would still apply the configured ACLs to the interface. If the module for some reason did not apply the ACL, the interface would have no `ip access-group` binding at all, resulting in no ACL filtering for either direction. The problem here is an ACL that is actually active but applying inbound, which indicates a successful application with the wrong direction parameter—not a failure to apply anything. Hence, this option does not explain the symptom.
Trap 3: The ACL itself is defined with the wrong direction in the playbook.
The ACL definition itself is direction-agnostic; it contains only match criteria (like source/destination addresses) and actions (permit/deny). The direction in which the ACL is evaluated is determined exclusively by the `direction` field in the interface's `access_groups` configuration, which is part of the module's interface-level parameters. If the ACL rules themselves were incorrect, the filtering action would be wrong irrespective of direction, but the symptom of applying inbound when outbound was intended points to the binding configuration, not the ACL content. Therefore, defining the ACL with a 'wrong direction' is not a valid explanation.
The routers have a different IOS version that interprets 'outbound' as 'in'.
Why it fails: The direction parameter is validated by the Ansible module itself, not by the router's IOS. The `ios_acl_interfaces` module only accepts the exact string values `in` or `out` for `direction`, so passing `outbound` would either cause a validation error or be ignored/defaulted; it cannot be reinterpreted by the device. Different IOS versions do not change how the module handles the parameter because the module runs on the control node and translates the validated value into the correct CLI command. Thus, the router's IOS version is irrelevant to the symptom.
The playbook uses 'direction: outbound' but the module expects 'direction: out'.
This is the root cause: `ios_acl_interfaces` requires `direction` to be literally `in` or `out`, and `outbound` is not a valid enum value. If the module does not immediately raise an argument-spec error, it may silently fall back to the default direction, which is `in`, thereby applying the ACL to inbound traffic. The observed behavior matches exactly: the ACL is active but filtering the wrong direction. Correcting the value to `out` would produce the intended outbound traffic filtering.
The engineer forgot to include the 'state: present' parameter, so the module did not apply the ACL.
Why it fails: In Ansible's `ios_acl_interfaces`, `state: present` is the default behavior, so omitting it would still apply the configured ACLs to the interface. If the module for some reason did not apply the ACL, the interface would have no `ip access-group` binding at all, resulting in no ACL filtering for either direction. The problem here is an ACL that is actually active but applying inbound, which indicates a successful application with the wrong direction parameter—not a failure to apply anything. Hence, this option does not explain the symptom.
The ACL itself is defined with the wrong direction in the playbook.
Why it fails: The ACL definition itself is direction-agnostic; it contains only match criteria (like source/destination addresses) and actions (permit/deny). The direction in which the ACL is evaluated is determined exclusively by the `direction` field in the interface's `access_groups` configuration, which is part of the module's interface-level parameters. If the ACL rules themselves were incorrect, the filtering action would be wrong irrespective of direction, but the symptom of applying inbound when outbound was intended points to the binding configuration, not the ACL content. Therefore, defining the ACL with a 'wrong direction' is not a valid explanation.
Trap 1: Fabric Control node
The Fabric Control node is the LISP control plane responsible for maintaining the Endpoint Identifier (EID) to Routing Locator (RLOC) mappings. It does not physically attach to any endpoints; wireless clients are registered with the Control node through the Fabric Edge, which discovers them. Since it only provides mapping and registration services, it cannot directly integrate or enforce policies on user traffic.
Trap 2: Fabric Border node
The Fabric Border node serves as the exit or entry point between the SD-Access fabric and external networks such as a WAN or the Internet. It translates VXLAN encapsulated traffic to traditional IP routing and applies inter-VRF routing policies for north-south flows, but it never terminates wireless user connections. Wireless endpoints are always attached to a Fabric Edge node, not a Border node.
Trap 3: Wireless LAN Controller (WLC)
While the Wireless LAN Controller (WLC) manages access points, handles RF, and supports roaming, in an SD-Access deployment it does not enforce segmentation or policy on wireless clients. The WLC forwards wireless traffic to the Fabric Edge, which applies VXLAN encapsulation, SGT-based policy, and anycast gateway features. Therefore, the WLC is a management component, not the policy-integration point for wireless users.
Fabric Edge node
The Fabric Edge node is the ingress point for every endpoint—wired or wireless—into the SD-Access fabric. It terminates VXLAN tunnels from access switches and wireless APs, hosts the anycast gateway for the subnet, and enforces policy via Cisco TrustSec (SGT-based segmentation) and ACLs. All user traffic enters here, making it the correct component for integrating policies and providing connectivity.
Fabric Control node
Why it fails: The Fabric Control node is the LISP control plane responsible for maintaining the Endpoint Identifier (EID) to Routing Locator (RLOC) mappings. It does not physically attach to any endpoints; wireless clients are registered with the Control node through the Fabric Edge, which discovers them. Since it only provides mapping and registration services, it cannot directly integrate or enforce policies on user traffic.
Fabric Border node
Why it fails: The Fabric Border node serves as the exit or entry point between the SD-Access fabric and external networks such as a WAN or the Internet. It translates VXLAN encapsulated traffic to traditional IP routing and applies inter-VRF routing policies for north-south flows, but it never terminates wireless user connections. Wireless endpoints are always attached to a Fabric Edge node, not a Border node.
Wireless LAN Controller (WLC)
Why it fails: While the Wireless LAN Controller (WLC) manages access points, handles RF, and supports roaming, in an SD-Access deployment it does not enforce segmentation or policy on wireless clients. The WLC forwards wireless traffic to the Fabric Edge, which applies VXLAN encapsulation, SGT-based policy, and anycast gateway features. Therefore, the WLC is a management component, not the policy-integration point for wireless users.
Trap 1: Fabric edge node
A fabric edge node is incorrect because its primary role is to connect end hosts to the fabric and to enforce intra-VN policies (e.g., VN segmentation and SGT-based ACLs) for traffic within the same virtual network. Edge nodes do not perform inter-VN policy-based routing by default; inter-VN traffic is typically sent to the border node for any required inspection or policy enforcement. While edge nodes can apply SGT-based access policies, they are not architected for inter-VN inspection scenarios where traffic must be redirected to a firewall — that redirection and inspection is a border-node function. Therefore, selecting the fabric edge node would mischaracterize the SD-Access design role for inter-VN traffic forwarding.
Trap 2: Fabric control plane node
A fabric control plane node is incorrect because it is a logical function (often co-located with a border node) that provides the LISP map server and map resolver services, maintaining the EID-to-RLOC mappings for all fabric devices. Control plane nodes do not participate in the data plane; they receive map-register and map-request messages but do not forward user data traffic. Since they do not forward traffic, they cannot enforce or apply packet-inspection policies like firewall redirection for inter-VN traffic. The control plane's role is purely signaling and mapping, so it is not the correct answer for a node that steers traffic to a firewall.
Trap 3: Fabric WAN router
A fabric WAN router is incorrect because its function is to provide connectivity from the SD-Access fabric to external wide-area networks (e.g., MPLS, Internet, or VPNs) at the network edge. While a WAN router can have routing policies, it is not the SD-Access component specifically designated for inter-VN policy enforcement; that role belongs to the fabric border node. In a typical SD-Access design, the WAN router connects to the border node (or is integrated into it) and does not natively participate in LISP or VXLAN forwarding within the fabric. Even if a WAN router could apply ACLs or PBR, it is not the architecturally correct point for steering inter-VN traffic to a firewall, whereas the border node has explicit LISP routing and policy-injection capabilities for that purpose.
Fabric border node
The fabric border node is the correct answer because it serves as the gateway between the SD-Access fabric and external networks (such as a data center or WAN). Critically, border nodes can apply policy-based routing (PBR) to inter-VN traffic, allowing it to be steered to an external firewall for inspection before being allowed to continue — a capability that makes the border node the natural point for inter-VN policy enforcement. In Cisco SD-Access, border nodes also perform LISP proxy-ETR (PETR) and proxy-ITR functionality, enabling them to handle traffic destined outside the fabric and to apply security policy at the network edge without needing a dedicated internal firewall. Thus, the border node is specifically designed to enforce inter-VN security policy, not just forward traffic.
Fabric edge node
Why it fails: A fabric edge node is incorrect because its primary role is to connect end hosts to the fabric and to enforce intra-VN policies (e.g., VN segmentation and SGT-based ACLs) for traffic within the same virtual network. Edge nodes do not perform inter-VN policy-based routing by default; inter-VN traffic is typically sent to the border node for any required inspection or policy enforcement. While edge nodes can apply SGT-based access policies, they are not architected for inter-VN inspection scenarios where traffic must be redirected to a firewall — that redirection and inspection is a border-node function. Therefore, selecting the fabric edge node would mischaracterize the SD-Access design role for inter-VN traffic forwarding.
Fabric control plane node
Why it fails: A fabric control plane node is incorrect because it is a logical function (often co-located with a border node) that provides the LISP map server and map resolver services, maintaining the EID-to-RLOC mappings for all fabric devices. Control plane nodes do not participate in the data plane; they receive map-register and map-request messages but do not forward user data traffic. Since they do not forward traffic, they cannot enforce or apply packet-inspection policies like firewall redirection for inter-VN traffic. The control plane's role is purely signaling and mapping, so it is not the correct answer for a node that steers traffic to a firewall.
Fabric WAN router
Why it fails: A fabric WAN router is incorrect because its function is to provide connectivity from the SD-Access fabric to external wide-area networks (e.g., MPLS, Internet, or VPNs) at the network edge. While a WAN router can have routing policies, it is not the SD-Access component specifically designated for inter-VN policy enforcement; that role belongs to the fabric border node. In a typical SD-Access design, the WAN router connects to the border node (or is integrated into it) and does not natively participate in LISP or VXLAN forwarding within the fabric. Even if a WAN router could apply ACLs or PBR, it is not the architecturally correct point for steering inter-VN traffic to a firewall, whereas the border node has explicit LISP routing and policy-injection capabilities for that purpose.
Trap 1: The switch is not configured for 802.1X on the interface.
This is incorrect because Cisco TrustSec does not strictly require 802.1X authentication on an interface. When the interface is configured with 'cts manual' and a manually assigned SGT is applied to untagged traffic, the switch can classify packets without any 802.1X session. The absence of 802.1X only means there is no dynamic authentication or SGT propagation via RADIUS, but manual SGT assignment can still be fully operational. Therefore, a missing 802.1X configuration does not explain why role-based policies are not enforced.
Trap 2: The 'cts manual' command is incorrect; 'cts dot1x' should be used…
This is wrong because 'cts manual' is a completely valid command for trusted interfaces where SGTs are manually assigned to untagged or non-802.1X traffic. It is not a typo or an invalid alternative to 'cts dot1x'—the two modes serve different purposes: 'cts dot1x' is used when the switch relies on 802.1X and RADIUS to dynamically receive SGTs, while 'cts manual' is used for static SGT assignment on trusted links. The problem is not the command syntax but that the SGT mappings themselves are missing on the switch, so the classification cannot occur regardless of which mode is configured.
Trap 3: The 'show cts role-based counters' command shows no drops,…
This is incorrect because 'show cts role-based counters' only displays the number of packets that were actually dropped by role-based access control lists. If enforcement is not active—for example, because the SGTs are missing or the RBACL is not applied to the relevant source/destination pair—the counters will remain at zero, even if an ACL is configured somewhere. The command does not show whether ACLs are configured or attached; it only shows the outcome of enforcement. Therefore, zero drops simply indicate that no packets were rejected, which is consistent with the switch lacking SGT mappings and never evaluating a policy.
The switch is not configured for 802.1X on the interface.
Why it fails: This is incorrect because Cisco TrustSec does not strictly require 802.1X authentication on an interface. When the interface is configured with 'cts manual' and a manually assigned SGT is applied to untagged traffic, the switch can classify packets without any 802.1X session. The absence of 802.1X only means there is no dynamic authentication or SGT propagation via RADIUS, but manual SGT assignment can still be fully operational. Therefore, a missing 802.1X configuration does not explain why role-based policies are not enforced.
The 'cts manual' command is incorrect; 'cts dot1x' should be used instead.
Why it fails: This is wrong because 'cts manual' is a completely valid command for trusted interfaces where SGTs are manually assigned to untagged or non-802.1X traffic. It is not a typo or an invalid alternative to 'cts dot1x'—the two modes serve different purposes: 'cts dot1x' is used when the switch relies on 802.1X and RADIUS to dynamically receive SGTs, while 'cts manual' is used for static SGT assignment on trusted links. The problem is not the command syntax but that the SGT mappings themselves are missing on the switch, so the classification cannot occur regardless of which mode is configured.
The SGTs are not being propagated to the switch; the switch lacks SGT mappings for the hosts.
This is correct because role-based enforcement in Cisco TrustSec depends entirely on the switch having a valid SGT mapping for the traffic source. If the SGT is not propagated via CTS/SXP/RADIUS or manually configured as an IP-SGT mapping, the switch cannot determine which SGT to assign to the hosts' traffic. Without that mapping, packets remain untagged or are assigned a default SGT, and the role-based ACL (RBACL) is never applied, so the expected drop does not happen. The root cause is the missing SGT propagation or mapping on the switch, not the interface mode.
The 'show cts role-based counters' command shows no drops, indicating the ACLs are not configured.
Why it fails: This is incorrect because 'show cts role-based counters' only displays the number of packets that were actually dropped by role-based access control lists. If enforcement is not active—for example, because the SGTs are missing or the RBACL is not applied to the relevant source/destination pair—the counters will remain at zero, even if an ACL is configured somewhere. The command does not show whether ACLs are configured or attached; it only shows the outcome of enforcement. Therefore, zero drops simply indicate that no packets were rejected, which is consistent with the switch lacking SGT mappings and never evaluating a policy.
Trap 1: The port connected to the DHCP server should be untrusted for DAI…
The DHCP server port must be configured as trusted, not untrusted, for DAI to operate correctly. DAI does not inspect ARP packets that arrive on trusted ports; an untrusted DHCP server port would cause DAI to drop the server's ARP messages, breaking DHCP and subsequent security verification.
Trap 2: The DHCP server is in a different VLAN, and DAI cannot validate…
DAI inspects ARP packets on a per-VLAN basis using the DHCP snooping binding table, which contains entries for multiple VLANs. The location of the DHCP server is irrelevant because its port is trusted and its ARP traffic is exempt from inspection; only the hosts' ARP messages are validated against their own VLAN's bindings.
Trap 3: DAI is checking the destination MAC address, which does not match…
DAI does not validate the destination MAC address in an Ethernet or ARP frame. Instead, it validates the sender hardware address and sender protocol address against the DHCP snooping binding table, then checks the frame's source MAC address. The destination is irrelevant to the binding check; DAI only cares who is speaking, not to whom the packet is directed.
The hosts have static IP addresses, so their MAC-IP bindings are not in the DHCP snooping database.
DAI validates ARP packets by looking up the source MAC and IP in the DHCP snooping binding table, which is populated only by DHCP-assigned addresses. Because these hosts use static IPs, no binding entry exists for them. Consequently, DAI will consider their ARP packets invalid and drop them unless an ARP ACL explicitly permits their IP-to-MAC mapping.
The port connected to the DHCP server should be untrusted for DAI to work correctly.
Why it fails: The DHCP server port must be configured as trusted, not untrusted, for DAI to operate correctly. DAI does not inspect ARP packets that arrive on trusted ports; an untrusted DHCP server port would cause DAI to drop the server's ARP messages, breaking DHCP and subsequent security verification.
The DHCP server is in a different VLAN, and DAI cannot validate cross-VLAN ARP.
Why it fails: DAI inspects ARP packets on a per-VLAN basis using the DHCP snooping binding table, which contains entries for multiple VLANs. The location of the DHCP server is irrelevant because its port is trusted and its ARP traffic is exempt from inspection; only the hosts' ARP messages are validated against their own VLAN's bindings.
DAI is checking the destination MAC address, which does not match the expected value.
Why it fails: DAI does not validate the destination MAC address in an Ethernet or ARP frame. Instead, it validates the sender hardware address and sender protocol address against the DHCP snooping binding table, then checks the frame's source MAC address. The destination is irrelevant to the binding check; DAI only cares who is speaking, not to whom the packet is directed.
Trap 1: VRF can be used to replace VLANs for Layer 2 isolation.
VRF provides Layer 3 routing table separation, not Layer 2 broadcast-domain isolation, so it cannot replace VLANs. It is tempting because VRFs and VLANs are both isolation mechanisms and are often mapped together, but VLANs segment Ethernet frames while VRFs segment IP routing instances.
Trap 2: In VRF-lite, path isolation is achieved using MPLS labels.
VRF-lite achieves path isolation through separate routing and forwarding tables on the same device, without MPLS labels; label-based isolation belongs to full MPLS L3VPN. It is tempting because both approaches separate customer traffic, but VRF-lite is specifically the label-free variant.
VRFs allow multiple customers to share the same physical infrastructure while keeping their traffic isolated.
VRFs provide logical separation at Layer 3 by maintaining independent routing and forwarding tables per customer on shared hardware. This satisfies the stem's path isolation requirement, letting overlapping address space coexist without leakage between tenants across the same physical service provider infrastructure.
In MPLS VPN, VRFs are combined with route targets to control route distribution between PE routers.
In MPLS VPN, route targets are extended BGP community attributes attached to VPNv4 routes, determining which VRFs import or export them. This controls route distribution between PE routers, satisfying the stem's requirement for combining VRFs with route targets.
VRF-aware features such as NAT, QoS, and ACLs can be applied per VRF to enforce path isolation policies.
VRF-aware NAT, QoS and ACLs operate within each routing table's forwarding context, so policy is enforced per tenant rather than globally. This satisfies the stem's path isolation requirement by keeping traffic separated end to end, letting each VRF carry independent filtering, marking and translation rules without leaking between customers.
VRF can be used to replace VLANs for Layer 2 isolation.
Why it fails: VRF provides Layer 3 routing table separation, not Layer 2 broadcast-domain isolation, so it cannot replace VLANs. It is tempting because VRFs and VLANs are both isolation mechanisms and are often mapped together, but VLANs segment Ethernet frames while VRFs segment IP routing instances.
In VRF-lite, path isolation is achieved using MPLS labels.
Why it fails: VRF-lite achieves path isolation through separate routing and forwarding tables on the same device, without MPLS labels; label-based isolation belongs to full MPLS L3VPN. It is tempting because both approaches separate customer traffic, but VRF-lite is specifically the label-free variant.
Drag or tap steps into the slots.
Drag a concept onto its matching description — or click a concept then click the description.
CPU overload from excessive control plane traffic
IP spoofing attacks
Rogue DHCP server
ARP cache poisoning
IP spoofing on access ports
Trap 1: Access Control List (ACL)
ACLs are static and applied per interface or globally. They do not provide the dynamic, group-based policy model of SD-Access. Managing ACLs across a large fabric for many departments is operationally complex and does not meet the requirement for scalable segmentation.
Trap 2: VLAN pool
VLAN pools are used in SD-Access to allocate VLANs to fabric-enabled switches, but they do not provide security segmentation between departments. They are a mechanism for VLAN assignment, not for enforcing group-based policies. VLANs alone do not offer the granular, identity-based segmentation required.
Trap 3: Virtual Routing and Forwarding (VRF)
VRFs provide Layer 3 segmentation but require configuration on every device and do not scale as dynamically as SGT-based policies. The scenario explicitly asks for segmentation without traditional VRFs on every switch, so VRF is not the correct solution here.
Access Control List (ACL)
Why it fails: ACLs are static and applied per interface or globally. They do not provide the dynamic, group-based policy model of SD-Access. Managing ACLs across a large fabric for many departments is operationally complex and does not meet the requirement for scalable segmentation.
Scalable Group Tag (SGT)
SGTs are used in Cisco SD-Access to provide micro-segmentation. Each endpoint is assigned an SGT, and group-based policies (SGACLs) enforce traffic between groups. This allows segmentation without traditional VRFs on every switch, meeting the requirement for secure departmental separation.
VLAN pool
Why it fails: VLAN pools are used in SD-Access to allocate VLANs to fabric-enabled switches, but they do not provide security segmentation between departments. They are a mechanism for VLAN assignment, not for enforcing group-based policies. VLANs alone do not offer the granular, identity-based segmentation required.
Virtual Routing and Forwarding (VRF)
Why it fails: VRFs provide Layer 3 segmentation but require configuration on every device and do not scale as dynamically as SGT-based policies. The scenario explicitly asks for segmentation without traditional VRFs on every switch, so VRF is not the correct solution here.
Trap 1: The fabric uses a single shared bridge domain across all edge nodes…
SD-Access can use a shared subnet for a virtual network, but it does not rely on a single shared Layer 2 bridge domain stretched across all edge nodes. Stretching one bridge domain would reintroduce flooding and scale problems. Instead, the overlay uses LISP and VXLAN so endpoints in the same virtual network appear local without a stretched Layer 2 domain.
Trap 2: The underlay uses VXLAN flooding to propagate endpoint reachability…
The SD-Access underlay is a routed Layer 3 fabric, typically using IS-IS, and does not use VXLAN flooding to propagate endpoint reachability. VXLAN is used in the overlay, and reachability is learned through the LISP control plane, not through flooding. Relying on flooding would not scale to thousands of endpoints as the scenario requires.
Trap 3: Fabric edge nodes use OSPF to advertise endpoint host routes into…
The SD-Access underlay carries only infrastructure reachability, such as loopbacks and fabric-enabled link networks, using IS-IS. Endpoint host routes are not advertised into the underlay with OSPF. Endpoint reachability is handled in the overlay by LISP, so this statement misrepresents how the fabric scales and how endpoints are resolved.
The fabric uses a single shared bridge domain across all edge nodes to avoid VLAN proliferation.
Why it fails: SD-Access can use a shared subnet for a virtual network, but it does not rely on a single shared Layer 2 bridge domain stretched across all edge nodes. Stretching one bridge domain would reintroduce flooding and scale problems. Instead, the overlay uses LISP and VXLAN so endpoints in the same virtual network appear local without a stretched Layer 2 domain.
The underlay uses VXLAN flooding to propagate endpoint reachability to all fabric edge nodes.
Why it fails: The SD-Access underlay is a routed Layer 3 fabric, typically using IS-IS, and does not use VXLAN flooding to propagate endpoint reachability. VXLAN is used in the overlay, and reachability is learned through the LISP control plane, not through flooding. Relying on flooding would not scale to thousands of endpoints as the scenario requires.
The LISP control plane in SD-Access registers endpoint EID-to-RLOC mappings so fabric edge nodes can resolve destinations without flooding the underlay.
In SD-Access, the LISP map server and map resolver track endpoint identifier to routing locator mappings. Fabric edge nodes register local endpoints and query the map server for remote ones, which provides a control-plane lookup instead of data-plane flooding. This is how the fabric scales to thousands of endpoints while avoiding broadcast or unknown unicast flooding across the underlay.
Cisco TrustSec security group tags are carried in the VXLAN Group Policy Option header so fabric edge nodes can enforce group-based ACLs.
SD-Access uses Cisco TrustSec to assign security group tags to endpoints. These tags are carried inside the VXLAN Group Policy Option header, allowing fabric edge nodes to enforce scalable group-based ACLs without relying on IP-based rules. This provides identity and group-based policy enforcement across the fabric, which is a core requirement in the scenario.
Fabric edge nodes use OSPF to advertise endpoint host routes into the underlay for reachability.
Why it fails: The SD-Access underlay carries only infrastructure reachability, such as loopbacks and fabric-enabled link networks, using IS-IS. Endpoint host routes are not advertised into the underlay with OSPF. Endpoint reachability is handled in the overlay by LISP, so this statement misrepresents how the fabric scales and how endpoints are resolved.
Drag or tap steps into the slots.
Trap 1: The Cisco DNA Center Intent API translating business intent into…
DNA Center is the management and automation platform that translates intent into fabric device configuration, but it does not sit in the data path. Once it provisions the edge nodes, policy enforcement happens on the network devices, not in the controller. Relying on DNA Center itself for per-packet enforcement of guest versus clinical traffic would fail because management-plane systems do not forward or filter user traffic.
Trap 2: The fabric control plane node running LISP map-server functions
The control plane node maintains the LISP mapping database of endpoint-to-routing-locator associations so fabric devices can resolve destinations. It does not inspect or enforce traffic policy between endpoint groups; it only provides reachability information. In this hospital scenario, it would help staff devices locate EHR servers, but it would not prevent guest users from reaching those servers, so it is not the enforcement point.
Trap 3: The fabric intermediate node forwarding VXLAN-encapsulated traffic…
Intermediate nodes are underlay routers or switches that transport VXLAN-encapsulated packets between fabric edge nodes; they operate on the outer header and do not inspect the original endpoint traffic or its security group tags. They provide scalable transit but no policy decisions. In the hospital design, an intermediate node would forward guest traffic toward an EHR server just as readily as clinical traffic, so it cannot enforce the isolation requirement.
The Cisco DNA Center Intent API translating business intent into device configuration
Why it fails: DNA Center is the management and automation platform that translates intent into fabric device configuration, but it does not sit in the data path. Once it provisions the edge nodes, policy enforcement happens on the network devices, not in the controller. Relying on DNA Center itself for per-packet enforcement of guest versus clinical traffic would fail because management-plane systems do not forward or filter user traffic.
The fabric control plane node running LISP map-server functions
Why it fails: The control plane node maintains the LISP mapping database of endpoint-to-routing-locator associations so fabric devices can resolve destinations. It does not inspect or enforce traffic policy between endpoint groups; it only provides reachability information. In this hospital scenario, it would help staff devices locate EHR servers, but it would not prevent guest users from reaching those servers, so it is not the enforcement point.
The fabric intermediate node forwarding VXLAN-encapsulated traffic between edge nodes
Why it fails: Intermediate nodes are underlay routers or switches that transport VXLAN-encapsulated packets between fabric edge nodes; they operate on the outer header and do not inspect the original endpoint traffic or its security group tags. They provide scalable transit but no policy decisions. In the hospital design, an intermediate node would forward guest traffic toward an EHR server just as readily as clinical traffic, so it cannot enforce the isolation requirement.
The fabric edge node applying Cisco TrustSec group-based access control lists
Fabric edge nodes encapsulate traffic in VXLAN and enforce group-based policy using Cisco TrustSec security group tags and scalable group ACLs derived from ISE policy. When a guest wireless user tries to reach an EHR server, the ingress edge node drops the packet based on the source and destination security group tags. This directly delivers the required isolation between guest and clinical traffic in the SD-Access fabric.
Trap 1: Move the policy-map from the control plane to the data plane…
CoPP is applied to the control plane with the service-policy input command under control-plane configuration. Applying a policy-map to the data plane interface polices transit traffic, not traffic destined to the route processor. That would not solve SNMP polling failures and would change the traffic handling for all packets on that interface, which is not the intended design.
Trap 2: Add a new class-map that matches BGP and apply a lower police rate…
BGP is already stable, so lowering the police rate for BGP would risk destabilizing routing adjacencies and is unrelated to the SNMP failures. The problem is the management class rate, not BGP. Modifying an unrelated class does not address the SNMP drops and could introduce new control-plane issues.
Trap 3: Change the exceed-action from drop to transmit so that SNMP packets…
Setting the exceed-action to transmit for the management class removes policing protection for that traffic. While it would stop SNMP drops, it also allows a flood of management-plane traffic to reach the route processor, defeating the purpose of CoPP. CoPP should protect the control plane while still permitting legitimate rates, not disable enforcement for a class.
Move the policy-map from the control plane to the data plane interface facing the SNMP server.
Why it fails: CoPP is applied to the control plane with the service-policy input command under control-plane configuration. Applying a policy-map to the data plane interface polices transit traffic, not traffic destined to the route processor. That would not solve SNMP polling failures and would change the traffic handling for all packets on that interface, which is not the intended design.
Add a new class-map that matches BGP and apply a lower police rate to it, then reattach the policy.
Why it fails: BGP is already stable, so lowering the police rate for BGP would risk destabilizing routing adjacencies and is unrelated to the SNMP failures. The problem is the management class rate, not BGP. Modifying an unrelated class does not address the SNMP drops and could introduce new control-plane issues.
Increase the police rate in the CLASS-MGMT class to a value that accommodates the normal SNMP and SSH burst rate.
SNMP polling and SSH generate bursty traffic to the route processor. An 8000 bps police rate is far below the normal management traffic rate, so conforming packets are transmitted but excess packets are dropped, causing intermittent SNMP failures. Raising the rate for that class to match observed management traffic preserves CoPP protection while allowing legitimate management polling to reach the control plane.
Change the exceed-action from drop to transmit so that SNMP packets are never discarded.
Why it fails: Setting the exceed-action to transmit for the management class removes policing protection for that traffic. While it would stop SNMP drops, it also allows a flood of management-plane traffic to reach the route processor, defeating the purpose of CoPP. CoPP should protect the control plane while still permitting legitimate rates, not disable enforcement for a class.
Trap 1: Remove the service-policy from the control plane and rely on QoS on…
Removing CoPP eliminates protection against control-plane floods and CPU exhaustion, which defeats the purpose of the deployment. Data-plane QoS does not police traffic punted to the route processor, so it cannot substitute. This option trades away the security posture rather than fixing the classification gap that causes SSH drops.
Trap 2: Increase the BGP class rate and move the SSH class into the BGP…
Merging SSH into the BGP class couples unrelated protocols and lets BGP bursts consume the bandwidth reserved for management access. The problem is a missing or misclassified SSH class, not insufficient BGP bandwidth. This approach also makes future troubleshooting harder because two very different traffic types share one policer.
Trap 3: Configure an ACL that permits only the jump host's IP and apply it…
Filtering by source in class-default affects all unmatched traffic patterns and does not give SSH its own guaranteed rate. The jump host's SSH would still be policed by whatever action class-default uses, so timeouts persist under load. Access control is useful, but it does not replace explicit protocol classification in CoPP.
Add a class-map matching TCP port 22 traffic and attach it to the policy-map with an appropriate rate and conform/exceed actions.
SSH traffic must be explicitly classified so CoPP can rate-limit it separately instead of letting it fall into a default or catch-all class that may be policed aggressively. Adding a TCP port 22 class with a suitable rate and transmit action preserves protection while guaranteeing management access. This is the standard CoPP design practice for management protocols.
Remove the service-policy from the control plane and rely on QoS on the data plane instead.
Why it fails: Removing CoPP eliminates protection against control-plane floods and CPU exhaustion, which defeats the purpose of the deployment. Data-plane QoS does not police traffic punted to the route processor, so it cannot substitute. This option trades away the security posture rather than fixing the classification gap that causes SSH drops.
Increase the BGP class rate and move the SSH class into the BGP class-map.
Why it fails: Merging SSH into the BGP class couples unrelated protocols and lets BGP bursts consume the bandwidth reserved for management access. The problem is a missing or misclassified SSH class, not insufficient BGP bandwidth. This approach also makes future troubleshooting harder because two very different traffic types share one policer.
Configure an ACL that permits only the jump host's IP and apply it as the match for the class-default class.
Why it fails: Filtering by source in class-default affects all unmatched traffic patterns and does not give SSH its own guaranteed rate. The jump host's SSH would still be policed by whatever action class-default uses, so timeouts persist under load. Access control is useful, but it does not replace explicit protocol classification in CoPP.
Trap 1: Configure a route map that matches the control-plane protocols and…
Route maps are used for routing policy decisions, not for classifying control-plane traffic for CoPP. CoPP classification uses class maps with match statements such as match access-group or match protocol, so a route map is not the required element.
Trap 2: Apply the policy map to all physical interfaces using the…
Applying the policy map to physical interfaces affects transit data-plane traffic, not traffic destined to the route processor. CoPP specifically targets control-plane traffic, so interface-level application would not protect the CPU from routing protocol or management floods.
Trap 3: Enable NetFlow on the router to export control-plane traffic…
NetFlow provides traffic visibility and accounting but does not enforce policing or protect the control plane. While it can help monitor traffic patterns, it is not a required configuration element for CoPP and does not rate-limit control-plane packets.
Configure a route map that matches the control-plane protocols and reference it in the policy map.
Why it fails: Route maps are used for routing policy decisions, not for classifying control-plane traffic for CoPP. CoPP classification uses class maps with match statements such as match access-group or match protocol, so a route map is not the required element.
Apply the policy map to all physical interfaces using the service-policy input command under interface configuration mode.
Why it fails: Applying the policy map to physical interfaces affects transit data-plane traffic, not traffic destined to the route processor. CoPP specifically targets control-plane traffic, so interface-level application would not protect the CPU from routing protocol or management floods.
Apply the policy map to the control plane using the service-policy input command under control-plane configuration mode.
CoPP requires a policy map to be attached to the control plane with service-policy input under control-plane configuration mode. Without this attachment, the class maps and policy map exist but are not enforced on control-plane traffic, leaving the route processor unprotected.
Enable NetFlow on the router to export control-plane traffic statistics to a collector.
Why it fails: NetFlow provides traffic visibility and accounting but does not enforce policing or protect the control plane. While it can help monitor traffic patterns, it is not a required configuration element for CoPP and does not rate-limit control-plane packets.
Drag or tap steps into the slots.
Trap 1: Configure OSPF to use a different DSCP value so it matches a…
Changing the DSCP value of OSPF packets is not a standard practice and would require modifications on all OSPF neighbors. CoPP classification is typically based on ACLs matching protocol and port numbers, not DSCP. This approach is complex and unlikely to resolve the issue without additional changes.
Trap 2: Remove the CoPP policy from the control plane and reapply it after…
Removing the CoPP policy entirely would eliminate control plane protection, leaving the router vulnerable to DoS attacks. While it might temporarily resolve the OSPF flapping, it does not maintain the required protection. The goal is to adjust the policy, not disable it, to balance security and routing stability.
Trap 3: Apply the CoPP policy only to the management plane interface…
CoPP is designed to protect the control plane, which handles routing protocol traffic. Applying it to the management plane interface would not protect the control plane from OSPF floods and would leave the router vulnerable. The management plane is separate and typically protected by other means like ACLs.
Increase the rate limit for the OSPF class in the CoPP policy.
OSPF adjacency flapping indicates that OSPF hello packets are being dropped due to the policer rate being too low. Increasing the rate limit for the OSPF class allows legitimate OSPF control traffic to pass while still protecting the control plane from excessive traffic. This is the correct action because it directly addresses the dropped OSPF packets without removing protection entirely.
Configure OSPF to use a different DSCP value so it matches a higher-priority class in the CoPP policy.
Why it fails: Changing the DSCP value of OSPF packets is not a standard practice and would require modifications on all OSPF neighbors. CoPP classification is typically based on ACLs matching protocol and port numbers, not DSCP. This approach is complex and unlikely to resolve the issue without additional changes.
Remove the CoPP policy from the control plane and reapply it after OSPF stabilizes.
Why it fails: Removing the CoPP policy entirely would eliminate control plane protection, leaving the router vulnerable to DoS attacks. While it might temporarily resolve the OSPF flapping, it does not maintain the required protection. The goal is to adjust the policy, not disable it, to balance security and routing stability.
Apply the CoPP policy only to the management plane interface instead of the control plane.
Why it fails: CoPP is designed to protect the control plane, which handles routing protocol traffic. Applying it to the management plane interface would not protect the control plane from OSPF floods and would leave the router vulnerable. The management plane is separate and typically protected by other means like ACLs.
Free account
Create a free account to save your results and see which topics improve across sessions.
Focused Acls And Copp sessions
Every question in these sessions is drawn from the Acls And Copp domain — nothing else.
Related practice questions
Move into related areas when this topic feels solid.
Sharpen your 350-401 knowledge of Architecture.
Work through 350-401 questions on Virtualization.
Practise 350-401 questions linked to Infrastructure.
Sharpen your 350-401 knowledge of Network Assurance.
Security practice questions for 350-401.
Work through 350-401 questions on Automation.
Practise eBGP/iBGP peering, path attributes, route selection and BGP troubleshooting.
Practise OSPF area types, LSA types, neighbour states and multi-area design.
Practise EIGRP DUAL, metrics, stub routing and route redistribution.
Practise VLAN configuration, trunk negotiation and inter-VLAN routing.
Practise RSTP, MSTP, port roles and STP protection features.
Practise extended ACLs, CoPP rate-limiting and control-plane protection.
A free account saves results across sessions and highlights which topics need work.
Sign up free