350-401 · topic practice
Practise ENCOR 350-401 Python For Network Automation practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.
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
Python For Network Automation questions test whether you can apply the concept in context, not just recognise a definition.
How the topic appears in realistic exam-style scenarios.
Which detail in the question changes the correct answer.
How to eliminate plausible but wrong options.
How to connect the question back to the wider exam objective.
Watch out for
Practice set
20 questions · select your answer, then reveal the explanation
Drag or tap steps into the slots.
Drag a concept onto its matching description — or click a concept then click the description.
Simplifies SSH connections to network devices
Provides a unified API for configuration and state retrieval
Enables parallel task execution across inventory
Supports asynchronous network device communication
Offers raw SSH protocol implementation
A network engineer runs the following command on Switch SW1:
SW1# show etherchannel summary
Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use N - not in use, no aggregation f - failed to allocate aggregator
M - not in use, minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port
Number of channel-groups in use: 1 Number of aggregators: 1
Group Port-channel Protocol Ports ------+-------------+-----------+-------------------------------------------- 1 Po1(SU) LACP Gi0/1(P) Gi0/2(P) Gi0/3(D)
Based on this output, what can be concluded?
Trap 1: The EtherChannel is using PAgP.
The EtherChannel is using PAgP. The output clearly shows the EtherChannel protocol as LACP (Link Aggregation Control Protocol, IEEE 802.3ad), not PAgP (Port Aggregation Protocol, Cisco proprietary). In the 'show etherchannel summary' output, the 'Protocol' column would list LACP, confirming that PAgP is not in use. PAgP and LACP are mutually exclusive, so this option is factually incorrect.
Trap 2: Port Gi0/3 is bundled in the channel.
Port Gi0/3 is bundled in the channel. In 'show etherchannel summary', each member port is assigned a flag: 'P' means the port is bundled and actively participating in the channel, while 'D' means the port is down or administratively down. Gi0/3 shows the flag 'D', not 'P', so it is not part of the active EtherChannel bundle. Only ports with the 'P' flag are actively forwarding traffic.
Trap 3: The port-channel is a Layer 3 interface.
The port-channel is a Layer 3 interface. The output identifies the port-channel's layer type via a flag on the logical interface: 'S' signifies a Layer 2 port-channel, whereas 'R' would denote a Layer 3 routed port-channel. Since the flag shown is 'S', the EtherChannel is operating at Layer 2, making this statement incorrect. A Layer 3 port-channel would require an 'R' flag and an IP address configured on the logical interface.
The EtherChannel is using PAgP.
Why it fails: The EtherChannel is using PAgP. The output clearly shows the EtherChannel protocol as LACP (Link Aggregation Control Protocol, IEEE 802.3ad), not PAgP (Port Aggregation Protocol, Cisco proprietary). In the 'show etherchannel summary' output, the 'Protocol' column would list LACP, confirming that PAgP is not in use. PAgP and LACP are mutually exclusive, so this option is factually incorrect.
Port Gi0/3 is bundled in the channel.
Why it fails: Port Gi0/3 is bundled in the channel. In 'show etherchannel summary', each member port is assigned a flag: 'P' means the port is bundled and actively participating in the channel, while 'D' means the port is down or administratively down. Gi0/3 shows the flag 'D', not 'P', so it is not part of the active EtherChannel bundle. Only ports with the 'P' flag are actively forwarding traffic.
The port-channel is a Layer 3 interface.
Why it fails: The port-channel is a Layer 3 interface. The output identifies the port-channel's layer type via a flag on the logical interface: 'S' signifies a Layer 2 port-channel, whereas 'R' would denote a Layer 3 routed port-channel. Since the flag shown is 'S', the EtherChannel is operating at Layer 2, making this statement incorrect. A Layer 3 port-channel would require an 'R' flag and an IP address configured on the logical interface.
The EtherChannel has two active member links.
The EtherChannel has two active member links. The 'P' flag appears on both Gi0/1 and Gi0/2, indicating that exactly two physical interfaces are bundled into the port-channel and are actively forwarding traffic. Since no other ports display the 'P' flag, the EtherChannel is active with two member links. Other ports, such as Gi0/3, show 'D' and are not part of the operational bundle, confirming the two-link count.
Trap 1: The VRF is missing the route-target export command.
The route-target export command is what attaches the route-target value to VPNv4 routes when the PE advertises them over MP-BGP. If export were missing, the remote PE would have no RT to match against its import list, and it would not install the routes into the VRF, so the PE could not ping remote sites. Since the PE can reach remote sites, the export RT must already be correctly configured, making this a false cause.
Trap 2: The PE router is not running a routing protocol with the CE router.
PE-CE connectivity in an L3VPN can use static routing as well as dynamic protocols such as OSPF, EIGRP, or BGP, so the absence of a dynamic routing protocol is not in itself a failure. As long as the CE has a static route pointing to the PE's VRF interface and the PE has a static route for the CE's subnet, traffic will flow. The observed symptom—CE unable to reach remote sites—points to the CE lacking any route toward the PE, not to a missing routing protocol.
Trap 3: The MPLS LDP is not enabled on the PE-CE link.
MPLS LDP is used to distribute labels for core transport between P and PE routers, and those labels carry VPNv4 traffic across the service provider backbone. The PE-CE link is a regular IP link that carries customer traffic, not an MPLS-labeled interface, so LDP on that link is neither required nor configured in a standard L3VPN. Therefore, this option describes a component that is irrelevant to the CE-to-PE forwarding failure.
The CE router does not have a default route pointing to the PE's VRF interface.
In an MPLS L3VPN, the CE router must have a route—either a default route or a specific prefix—that points toward the PE's VRF-facing interface as the next hop. Without such a route, the CE cannot forward packets to the PE for remote VPN destinations, so pings from the CE fail. The PE can still ping remote sites because its VRF routing table contains the remote VPNv4 routes, which proves the problem is the CE's missing next hop rather than the PE's VRF configuration.
The VRF is missing the route-target export command.
Why it fails: The route-target export command is what attaches the route-target value to VPNv4 routes when the PE advertises them over MP-BGP. If export were missing, the remote PE would have no RT to match against its import list, and it would not install the routes into the VRF, so the PE could not ping remote sites. Since the PE can reach remote sites, the export RT must already be correctly configured, making this a false cause.
The PE router is not running a routing protocol with the CE router.
Why it fails: PE-CE connectivity in an L3VPN can use static routing as well as dynamic protocols such as OSPF, EIGRP, or BGP, so the absence of a dynamic routing protocol is not in itself a failure. As long as the CE has a static route pointing to the PE's VRF interface and the PE has a static route for the CE's subnet, traffic will flow. The observed symptom—CE unable to reach remote sites—points to the CE lacking any route toward the PE, not to a missing routing protocol.
The MPLS LDP is not enabled on the PE-CE link.
Why it fails: MPLS LDP is used to distribute labels for core transport between P and PE routers, and those labels carry VPNv4 traffic across the service provider backbone. The PE-CE link is a regular IP link that carries customer traffic, not an MPLS-labeled interface, so LDP on that link is neither required nor configured in a standard L3VPN. Therefore, this option describes a component that is irrelevant to the CE-to-PE forwarding failure.
Trap 1: SW2 has a lower priority than SW1, so it takes longer to become the…
Incorrect because the root bridge election is decided by bridge priority, but the priority value has no effect on convergence timing. Rapid PVST+ uses RSTP's proposal/agreement mechanism to rapidly transition ports to forwarding, and this occurs in milliseconds regardless of which switch is elected root. A lower priority on SW2 would only make it more likely to be root under normal operation; it would never cause it to 'take longer' to become root after a failure, since convergence speed is determined by protocol state machines and timers, not by priority.
Trap 2: BPDU Guard is enabled on the uplink ports, which prevents BPDU…
Incorrect because BPDU Guard is a PortFast security feature that error-disables a port the moment it receives any BPDU, to prevent unauthorized switches from participating in spanning tree. It does not filter, drop, or slow BPDU exchange while the link is up; rather, it shuts the port down completely, which would cause an immediate loss of connectivity, not a delay in convergence. On normal uplink ports BPDU Guard is not enabled, and even if it were, it would not alter the STP timers or slow down the root port failover process.
Trap 3: Loop Guard is enabled on the uplink ports, which delays port…
Incorrect because Loop Guard is designed to protect against unidirectional link failures by blocking a port that stops receiving BPDUs, placing it in a loop-inconsistent state. It does not add any artificial delay to the normal forwarding transition process; instead, it actively prevents a port from becoming designated when BPDUs are absent, which is a safety measure, not a timer-based delay. Loop Guard would only interfere after a BPDU loss and would block the port entirely, so it cannot explain the slower convergence caused by using legacy STP timers.
UplinkFast is enabled, which is incompatible with Rapid PVST+ and causes the switch to use legacy STP convergence.
Correct because UplinkFast is a proprietary Cisco feature designed for legacy 802.1D PVST+ to quickly fail over to a precomputed alternate root port when the primary uplink fails. However, UplinkFast is mutually exclusive with Rapid PVST+/RSTP, and when enabled it forces the switch to fall back to the classic Spanning Tree Protocol algorithm. That legacy mode relies on Max Age (20 seconds) and Forward Delay (15 seconds) timers, so after a root port failure the switch takes 30–50 seconds to converge instead of milliseconds, matching the behavior described.
SW2 has a lower priority than SW1, so it takes longer to become the root bridge after failure.
Why it fails: Incorrect because the root bridge election is decided by bridge priority, but the priority value has no effect on convergence timing. Rapid PVST+ uses RSTP's proposal/agreement mechanism to rapidly transition ports to forwarding, and this occurs in milliseconds regardless of which switch is elected root. A lower priority on SW2 would only make it more likely to be root under normal operation; it would never cause it to 'take longer' to become root after a failure, since convergence speed is determined by protocol state machines and timers, not by priority.
BPDU Guard is enabled on the uplink ports, which prevents BPDU exchange.
Why it fails: Incorrect because BPDU Guard is a PortFast security feature that error-disables a port the moment it receives any BPDU, to prevent unauthorized switches from participating in spanning tree. It does not filter, drop, or slow BPDU exchange while the link is up; rather, it shuts the port down completely, which would cause an immediate loss of connectivity, not a delay in convergence. On normal uplink ports BPDU Guard is not enabled, and even if it were, it would not alter the STP timers or slow down the root port failover process.
Loop Guard is enabled on the uplink ports, which delays port transition.
Why it fails: Incorrect because Loop Guard is designed to protect against unidirectional link failures by blocking a port that stops receiving BPDUs, placing it in a loop-inconsistent state. It does not add any artificial delay to the normal forwarding transition process; instead, it actively prevents a port from becoming designated when BPDUs are absent, which is a safety measure, not a timer-based delay. Loop Guard would only interfere after a BPDU loss and would block the port entirely, so it cannot explain the slower convergence caused by using legacy STP timers.
Trap 1: The engineer used 'ip default-network' which is not supported in…
Ly states that 'default-information originate' should be used for EIGRP. That command is for OSPF, not EIGRP. While 'ip default-network' is indeed not supported in EIGRP, the correct method is to redistribute a properly configured static default route, not to use 'default-information originate'. Therefore, this is not the most likely reason.
Trap 2: The internal routers have a route to the default network with a…
Internal routers are not receiving the default route at all, so they cannot have a route with a better metric from another source. This option describes a scenario where the route is received but not preferred, which does not match the problem.
Trap 3: The engineer needs to configure 'eigrp stub' on the router to allow…
Configuring 'eigrp stub' on the router would restrict route advertisement, not allow it. To advertise a default route from a stub router, you would need the 'summary' keyword, but the router is not necessarily a stub. This would not be the most likely reason for the failure.
The engineer used 'ip default-network' which is not supported in EIGRP; instead, 'default-information originate' should be used.
Why it fails: Ly states that 'default-information originate' should be used for EIGRP. That command is for OSPF, not EIGRP. While 'ip default-network' is indeed not supported in EIGRP, the correct method is to redistribute a properly configured static default route, not to use 'default-information originate'. Therefore, this is not the most likely reason.
The static default route is not configured correctly; the engineer should use 'ip route 0.0.0.0 0.0.0.0 <next-hop>'.
Correct. The static default route must be correctly configured with a next-hop IP address. If the static route is missing or uses an interface instead of a next-hop, it may not be valid, and the redistribution will not propagate the route to internal routers, despite appearing in the topology table with a metric.
The internal routers have a route to the default network with a better metric from another source.
Why it fails: Internal routers are not receiving the default route at all, so they cannot have a route with a better metric from another source. This option describes a scenario where the route is received but not preferred, which does not match the problem.
The engineer needs to configure 'eigrp stub' on the router to allow default route advertisement.
Why it fails: Configuring 'eigrp stub' on the router would restrict route advertisement, not allow it. To advertise a default route from a stub router, you would need the 'summary' keyword, but the router is not necessarily a stub. This would not be the most likely reason for the failure.
Trap 1: The VXLAN tunnel interface on the spine
Spine switches in an ACI fabric forward VXLAN-encapsulated traffic based on the fabric's forwarding tables but do not host EPG-level contract enforcement. Contract policy is enforced at the leaf where endpoints attach, so the spine tunnel interface is not the enforcement point described.
Trap 2: The bridge domain subnet SVI on the border leaf
A bridge domain SVI provides default gateway functionality for a subnet, not contract enforcement between EPGs. Contracts are applied at the leaf access policy layer using the EPG and contract relationship, so the SVI is not where the permitted TCP port 443 rule is enforced.
Trap 3: The APIC controller cluster policy compiler
The APIC cluster compiles and distributes policy to the leaves but does not sit in the data path, so it cannot enforce the TCP 443 permit rule on live traffic. Enforcement occurs on the leaf switch hardware, making APIC the policy source rather than the enforcement point.
The VXLAN tunnel interface on the spine
Why it fails: Spine switches in an ACI fabric forward VXLAN-encapsulated traffic based on the fabric's forwarding tables but do not host EPG-level contract enforcement. Contract policy is enforced at the leaf where endpoints attach, so the spine tunnel interface is not the enforcement point described.
The bridge domain subnet SVI on the border leaf
Why it fails: A bridge domain SVI provides default gateway functionality for a subnet, not contract enforcement between EPGs. Contracts are applied at the leaf access policy layer using the EPG and contract relationship, so the SVI is not where the permitted TCP port 443 rule is enforced.
The policy enforcement point on the leaf where the EPGs reside
In ACI, the leaf switch acts as the policy enforcement point, translating contracts into hardware ACL and forwarding rules applied to the EPG interfaces. When a contract permitting TCP 443 is attached between EPGs, the leaf enforces that filter for traffic between them, which is exactly the construct required.
The APIC controller cluster policy compiler
Why it fails: The APIC cluster compiles and distributes policy to the leaves but does not sit in the data path, so it cannot enforce the TCP 443 permit rule on live traffic. Enforcement occurs on the leaf switch hardware, making APIC the policy source rather than the enforcement point.
Trap 1: Assign the guest VRF to a separate VLAN and configure inter-VLAN…
Assigning a separate VLAN and enabling inter-VLAN routing would actually allow communication between the VRFs if the switch routes between them. Inter-VLAN routing connects subnets, which could defeat isolation. To maintain isolation, you must not enable routing between the VRFs unless explicitly desired. This step does not enforce isolation.
Trap 2: Configure a route target export and import policy to control route…
Route targets are used in MPLS L3VPN and EVPN to control route distribution between VRFs. On a standalone Catalyst 9000, VRFs are isolated by default, and route leaking is not controlled by route targets. While route targets can be used in VRF-lite with BGP, they are not the primary isolation mechanism on a single switch. This is not the required step for basic isolation.
Trap 3: Enable VRF-aware routing and ensure no static routes point between…
VRF-aware routing is automatic once interfaces are assigned to VRFs. The key is to avoid configuring routes that cross VRFs. However, the question asks for the required step to maintain isolation. The most fundamental step is to place interfaces into the correct VRF. This option is partially correct but not the specific configuration step that enforces isolation.
Assign the guest VRF to a separate VLAN and configure inter-VLAN routing.
Why it fails: Assigning a separate VLAN and enabling inter-VLAN routing would actually allow communication between the VRFs if the switch routes between them. Inter-VLAN routing connects subnets, which could defeat isolation. To maintain isolation, you must not enable routing between the VRFs unless explicitly desired. This step does not enforce isolation.
Configure a route target export and import policy to control route leaking.
Why it fails: Route targets are used in MPLS L3VPN and EVPN to control route distribution between VRFs. On a standalone Catalyst 9000, VRFs are isolated by default, and route leaking is not controlled by route targets. While route targets can be used in VRF-lite with BGP, they are not the primary isolation mechanism on a single switch. This is not the required step for basic isolation.
Place the guest network interfaces into the guest VRF and do not configure any route leaking.
VRF instances are isolated by default. By assigning interfaces to the guest VRF, traffic within that VRF is separate from the corporate VRF. As long as no route leaking (such as static routes or BGP route targets) is configured, the VRFs remain isolated. This is the correct and sufficient step to maintain isolation.
Enable VRF-aware routing and ensure no static routes point between VRFs.
Why it fails: VRF-aware routing is automatic once interfaces are assigned to VRFs. The key is to avoid configuring routes that cross VRFs. However, the question asks for the required step to maintain isolation. The most fundamental step is to place interfaces into the correct VRF. This option is partially correct but not the specific configuration step that enforces isolation.
Trap 1: The routers are configured with a different enable secret that does…
An incorrect enable secret in the Ansible vault would produce an immediate authentication failure — IOS would return '% Bad secrets' or 'Enable password incorrect' — causing the task to error out, not hang while waiting for a prompt. The indefinite wait suggests Ansible never even attempted to send the enable command because it did not know to use enable as the become method. Thus the failure is a missing escalation configuration, not a credential mismatch.
Trap 2: The SSH key exchange is taking longer than the default 12-second…
SSH key exchange and the default 12-second connection timeout occur during transport establishment, before the CLI session is interactive; a problem there would surface as an unreachable host or 'SSH Error: timeout' without ever reaching a prompt. The described symptom specifically involves waiting for a shell/privilege prompt after the SSH session is already up, so it cannot be caused by key exchange latency. Therefore it is a post-authentication escalation issue, not a transport-layer timeout.
Trap 3: The ios_command module requires a different privilege level to…
The ios_command module does not enforce privilege levels; the device does, and 'show ip route' would at worst produce an IOS authorization error such as 'Invalid input' if executed from a restricted view, not an indefinite wait. The timeout shown indicates the session was never elevated to privileged EXEC mode, so the command was never actually sent. That points to the missing become_method setting, not to a requirement that the command run at a different privilege level.
The routers are configured with a different enable secret that does not match the one in the Ansible vault.
Why it fails: An incorrect enable secret in the Ansible vault would produce an immediate authentication failure — IOS would return '% Bad secrets' or 'Enable password incorrect' — causing the task to error out, not hang while waiting for a prompt. The indefinite wait suggests Ansible never even attempted to send the enable command because it did not know to use enable as the become method. Thus the failure is a missing escalation configuration, not a credential mismatch.
The 'ansible_connection' is set to 'network_cli' but the 'ansible_become_method' is not set to 'enable'.
With ansible_connection: network_cli, Ansible must be told to escalate privileges by setting ansible_become: yes and ansible_become_method: enable. If the become method is omitted, the automation engine has no way to issue the enable command, so IOS remains at the user EXEC prompt and Ansible times out waiting for a privileged prompt that never arrives. The ios_command tasks then fail with a 'timeout waiting for privilege escalation prompt' error instead of returning command output.
The SSH key exchange is taking longer than the default 12-second timeout.
Why it fails: SSH key exchange and the default 12-second connection timeout occur during transport establishment, before the CLI session is interactive; a problem there would surface as an unreachable host or 'SSH Error: timeout' without ever reaching a prompt. The described symptom specifically involves waiting for a shell/privilege prompt after the SSH session is already up, so it cannot be caused by key exchange latency. Therefore it is a post-authentication escalation issue, not a transport-layer timeout.
The ios_command module requires a different privilege level to execute 'show ip route'.
Why it fails: The ios_command module does not enforce privilege levels; the device does, and 'show ip route' would at worst produce an IOS authorization error such as 'Invalid input' if executed from a restricted view, not an indefinite wait. The timeout shown indicates the session was never elevated to privileged EXEC mode, so the command was never actually sent. That points to the missing become_method setting, not to a requirement that the command run at a different privilege level.
Trap 1: The IP SLA DNS probe must be configured with a 'timeout' value…
The statement suggests setting a timeout lower than 50 ms to detect failure, but that would only cause false failures because the RTT is exactly 50 ms for a valid cached response. The real problem is not that the probe is too slow; it is that the probe is answered from the router's cache, so it never touches the network. Lowering the timeout below the observed RTT would make the probe time out even when the server is healthy, which is not a legitimate detection of the server's actual reachability. The timeout parameter determines how long the router waits for a reply; it cannot force the probe to bypass the local DNS cache.
Trap 2: The DNS server is responding to the probe but not to other queries…
This claim is incorrect because IP SLA DNS probes and standard DNS queries both use the same default destination port, UDP 53. The server does not treat traffic from an IP SLA probe differently based on source port, and the probe uses the identical DNS packet format as a normal query. If the server were reachable and responding to the probe, it would also respond to any other DNS query sent to the same destination IP and port. The reason the probe succeeds while other queries fail is that the probe's response is generated locally by the router's cache, not by the server.
Trap 3: The IP SLA operation is configured with a 'frequency' that is too…
The frequency parameter in IP SLA controls the interval between successive probes, not the behavior of any individual probe. A low frequency (e.g., a long interval) means probes are sent less often, but each probe still goes out and waits for a response according to its configured timeout. The server does not need to be "ready" at a certain time; it either answers or it does not. Since the probe in question is receiving a cached response, the frequency setting is irrelevant—changing it will not cause the probe to actually reach the DNS server or expose the server's unavailability.
The IP SLA DNS probe is using a cached DNS response from the router's DNS resolver, so it does not actually query the server.
The IP SLA DNS probe is designed to send a DNS query to a specified server and measure the response time. If the router's DNS resolver has caching enabled and has previously resolved the queried name, it may answer from its local cache without ever transmitting the query to the configured DNS server. This results in a successful probe with a low RTT (e.g., 50 ms) even when the actual DNS server is unreachable, because the reply comes from the router itself. To avoid this, the DNS name used in the probe must be unique or DNS caching must be disabled to force an end-to-end query.
The IP SLA DNS probe must be configured with a 'timeout' value lower than 50 ms to detect the failure.
Why it fails: The statement suggests setting a timeout lower than 50 ms to detect failure, but that would only cause false failures because the RTT is exactly 50 ms for a valid cached response. The real problem is not that the probe is too slow; it is that the probe is answered from the router's cache, so it never touches the network. Lowering the timeout below the observed RTT would make the probe time out even when the server is healthy, which is not a legitimate detection of the server's actual reachability. The timeout parameter determines how long the router waits for a reply; it cannot force the probe to bypass the local DNS cache.
The DNS server is responding to the probe but not to other queries because the probe uses a different port.
Why it fails: This claim is incorrect because IP SLA DNS probes and standard DNS queries both use the same default destination port, UDP 53. The server does not treat traffic from an IP SLA probe differently based on source port, and the probe uses the identical DNS packet format as a normal query. If the server were reachable and responding to the probe, it would also respond to any other DNS query sent to the same destination IP and port. The reason the probe succeeds while other queries fail is that the probe's response is generated locally by the router's cache, not by the server.
The IP SLA operation is configured with a 'frequency' that is too low, causing the probe to be sent before the server times out.
Why it fails: The frequency parameter in IP SLA controls the interval between successive probes, not the behavior of any individual probe. A low frequency (e.g., a long interval) means probes are sent less often, but each probe still goes out and waits for a response according to its configured timeout. The server does not need to be "ready" at a certain time; it either answers or it does not. Since the probe in question is receiving a cached response, the frequency setting is irrelevant—changing it will not cause the probe to actually reach the DNS server or expose the server's unavailability.
Trap 1: The WLC is configured with the wrong authentication port; RADIUS…
This is incorrect because RADIUS authentication uses UDP port 1812 as the IANA-assigned standard port; port 1645 is a legacy alternative from early RADIUS implementations that has been deprecated due to conflicts with the datametrics service. More importantly, the server logs in the scenario show that the WLC's Access-Request messages are being received, which proves the WLC is sending to the correct destination port (1812). If the WLC were mistakenly configured for 1645, the requests would never reach the RADIUS listener on 1812, and no Access-Reject entries would appear in the server logs.
Trap 2: The WLC's RADIUS server configuration has the wrong shared secret,…
Incorrect because the server logs show 'Access-Reject', which indicates the server received the request and processed it; a shared secret mismatch would typically result in no response or a 'Access-Challenge' but not necessarily a reject. However, the server could still reject if the secret is wrong, but the WLC would still see a response, not 'server not responding'.
Trap 3: The WLC is not configured with a valid management interface IP…
This is incorrect because the RADIUS server logs show that it is receiving Access-Request packets from the WLC, which proves the WLC's management interface has a valid IP address and can route to the server. An invalid management interface IP (or missing route) would prevent the WLC from sourcing or sending any RADIUS traffic, so the server would see nothing at all. The real issue is asymmetric routing or a source-address mismatch: the server replies from a different IP than the configured RADIUS server address, causing the WLC to drop those responses and log 'server not responding'.
The RADIUS server is configured to use a different source IP address for RADIUS responses than the IP address configured on the WLC, causing the WLC to drop the responses.
Correct because the WLC typically expects RADIUS responses to come from the same IP address as the configured server; if the server uses a different source IP (e.g., a loopback or secondary IP), the WLC may not recognize the response and logs 'server not responding'.
The WLC is configured with the wrong authentication port; RADIUS uses port 1645, not 1812.
Why it fails: This is incorrect because RADIUS authentication uses UDP port 1812 as the IANA-assigned standard port; port 1645 is a legacy alternative from early RADIUS implementations that has been deprecated due to conflicts with the datametrics service. More importantly, the server logs in the scenario show that the WLC's Access-Request messages are being received, which proves the WLC is sending to the correct destination port (1812). If the WLC were mistakenly configured for 1645, the requests would never reach the RADIUS listener on 1812, and no Access-Reject entries would appear in the server logs.
The WLC's RADIUS server configuration has the wrong shared secret, causing the server to reject requests.
Why it fails: Incorrect because the server logs show 'Access-Reject', which indicates the server received the request and processed it; a shared secret mismatch would typically result in no response or a 'Access-Challenge' but not necessarily a reject. However, the server could still reject if the secret is wrong, but the WLC would still see a response, not 'server not responding'.
The WLC is not configured with a valid management interface IP address to reach the RADIUS server.
Why it fails: This is incorrect because the RADIUS server logs show that it is receiving Access-Request packets from the WLC, which proves the WLC's management interface has a valid IP address and can route to the server. An invalid management interface IP (or missing route) would prevent the WLC from sourcing or sending any RADIUS traffic, so the server would see nothing at all. The real issue is asymmetric routing or a source-address mismatch: the server replies from a different IP than the configured RADIUS server address, causing the WLC to drop those responses and log 'server not responding'.
Trap 1: The AS-path contains the local AS number.
This is incorrect. While an AS-path containing the local AS number can cause routes to be rejected due to loop prevention, the typical symptom is routes not being received at all or being marked as invalid, not the specific 'received but not valid' status. The most common cause for 'not valid' is next-hop unreachability.
Trap 2: BGP synchronization is enabled.
This is incorrect. BGP synchronization is a legacy feature that requires the route to be in the IGP before it is advertised. In modern networks, synchronization is disabled by default. Even if enabled, it affects advertisement, not the validity of received routes in the BGP table.
Trap 3: The maximum-prefix limit has been exceeded.
This is incorrect. Exceeding the maximum-prefix limit typically causes the BGP session to reset or routes to be withdrawn, not to be marked as 'not valid' in the BGP table. Routes would likely be removed entirely, not just marked invalid.
The AS-path contains the local AS number.
Why it fails: This is incorrect. While an AS-path containing the local AS number can cause routes to be rejected due to loop prevention, the typical symptom is routes not being received at all or being marked as invalid, not the specific 'received but not valid' status. The most common cause for 'not valid' is next-hop unreachability.
The next-hop IP address is not reachable.
Correct. For a BGP route to be considered valid and installed in the routing table, the next-hop IP address must be reachable via an IGP or static route. If the next hop is not reachable, the route will appear in the 'show ip bgp' output but be marked as not valid.
BGP synchronization is enabled.
Why it fails: This is incorrect. BGP synchronization is a legacy feature that requires the route to be in the IGP before it is advertised. In modern networks, synchronization is disabled by default. Even if enabled, it affects advertisement, not the validity of received routes in the BGP table.
The maximum-prefix limit has been exceeded.
Why it fails: This is incorrect. Exceeding the maximum-prefix limit typically causes the BGP session to reset or routes to be withdrawn, not to be marked as 'not valid' in the BGP table. Routes would likely be removed entirely, not just marked invalid.
Trap 1: The router's interface is configured with the no ip…
The `no ip forward-protocol udp bootps` command disables the forwarding of UDP broadcasts destined for BOOTPS/DHCP port 67 by the relay agent. However, the router here is acting as the DHCP server itself, not as a relay. A local DHCP server receives DHCPDISCOVER broadcasts natively on its directly connected interface, so this command has no effect on the server's ability to see those broadcasts. This option is incorrect because it targets the relay function rather than the local server reception.
Trap 2: The DHCP pool is configured with the wrong default-router option.
The `default-router` option in a DHCP pool sets the gateway address that the client will configure via the DHCPOFFER message. This option does not influence whether the router receives the DHCPDISCOVER or whether the server responds to it. A wrong default-router address would cause the client to have an incorrect gateway after obtaining an address, but it would not prevent the client from being assigned an IP. Therefore, this cannot explain a complete failure to receive broadcast messages.
Trap 3: The router's DHCP server is disabled globally with the no service…
The global `no service dhcp` command disables both the DHCP server and relay functionality on the router. If this were the cause, the router would not respond to any DHCP requests, but when an engineer attempts to configure a DHCP pool, Cisco IOS displays an error like 'DHCP is disabled on this router' or requires the `service dhcp` command to be enabled. Since the pool is presumably configured and active, the service must be running, making this option unlikely. This option is incorrect because the failure mode would be immediately apparent during configuration, not a silent absence of DHCPDISCOVER reception.
The router's interface is configured with the no ip forward-protocol udp bootps command.
Why it fails: The `no ip forward-protocol udp bootps` command disables the forwarding of UDP broadcasts destined for BOOTPS/DHCP port 67 by the relay agent. However, the router here is acting as the DHCP server itself, not as a relay. A local DHCP server receives DHCPDISCOVER broadcasts natively on its directly connected interface, so this command has no effect on the server's ability to see those broadcasts. This option is incorrect because it targets the relay function rather than the local server reception.
The router's interface is not in the same VLAN as the client, and no ip helper-address is configured.
This is correct because DHCP clients use Layer 2 broadcast (destination FF:FF:FF:FF:FF:FF) to send DHCPDISCOVER messages, and broadcasts never cross a Layer 3 boundary by default. If the router's interface is in a different VLAN from the client, the broadcast stays confined to the client's broadcast domain. To reach a DHCP server in another subnet, you must configure an `ip helper-address` on the client's VLAN interface, which converts the broadcast into a unicast (or directed broadcast) to the DHCP server. Without that relay, the router will never receive the DISCOVER because it is not on the same VLAN.
The DHCP pool is configured with the wrong default-router option.
Why it fails: The `default-router` option in a DHCP pool sets the gateway address that the client will configure via the DHCPOFFER message. This option does not influence whether the router receives the DHCPDISCOVER or whether the server responds to it. A wrong default-router address would cause the client to have an incorrect gateway after obtaining an address, but it would not prevent the client from being assigned an IP. Therefore, this cannot explain a complete failure to receive broadcast messages.
The router's DHCP server is disabled globally with the no service dhcp command.
Why it fails: The global `no service dhcp` command disables both the DHCP server and relay functionality on the router. If this were the cause, the router would not respond to any DHCP requests, but when an engineer attempts to configure a DHCP pool, Cisco IOS displays an error like 'DHCP is disabled on this router' or requires the `service dhcp` command to be enabled. Since the pool is presumably configured and active, the service must be running, making this option unlikely. This option is incorrect because the failure mode would be immediately apparent during configuration, not a silent absence of DHCPDISCOVER reception.
Trap 1: The switch must have 'aaa authentication dot1x default group…
This global configuration is already assumed to be in place in the scenario, as the switch is attempting 802.1X authentication and the failure occurs at the interface level. The command 'aaa authentication dot1x default group radius' only specifies the authentication method and server; it has no role in assigning a VLAN to a failed or unauthenticated host. The missing piece is the interface-specific guest VLAN definition, not a global authentication rule.
Trap 2: The 'authentication host-mode multi-host' command should be…
Replacing 'multi-host' with 'multi-domain' would change how multiple devices are authenticated on the port, but it does not affect whether a guest VLAN can be used. 'Multi-domain' restricts the port to one voice and one data device, while 'multi-host' allows any number of devices after a single successful authentication. Both host modes support a guest VLAN; the actual problem is that no guest VLAN has been configured with the 'authentication guest-vlan' command.
Trap 3: The port must be configured as a trunk port to allow the guest VLAN.
The guest VLAN is a single, untagged VLAN that the switch dynamically assigns to an access port when authentication fails; it is not a trunk VLAN. Trunk ports are designed to carry multiple VLANs with tagging, which would introduce unnecessary complexity and security risk for a guest access environment. A standard access port with 'authentication guest-vlan' is sufficient, and the command works regardless of the port's trunk or access mode—but using trunk would not solve the missing VLAN definition.
The interface needs the 'authentication guest-vlan <vlan-id>' command to specify the VLAN for non-802.1X devices.
The interface-level command 'authentication guest-vlan <vlan-id>' is required to define a fallback VLAN for devices that do not respond to 802.1X or whose authentication times out. Without this command, a non-802.1X capable device will be denied access or left in an unauthorized state, because the switch has no VLAN to assign it. The guest VLAN is a per-interface configuration, separate from global AAA commands, and it must reference an existing VLAN on the switch.
The switch must have 'aaa authentication dot1x default group radius' configured globally.
Why it fails: This global configuration is already assumed to be in place in the scenario, as the switch is attempting 802.1X authentication and the failure occurs at the interface level. The command 'aaa authentication dot1x default group radius' only specifies the authentication method and server; it has no role in assigning a VLAN to a failed or unauthenticated host. The missing piece is the interface-specific guest VLAN definition, not a global authentication rule.
The 'authentication host-mode multi-host' command should be replaced with 'authentication host-mode multi-domain' to support guest VLAN.
Why it fails: Replacing 'multi-host' with 'multi-domain' would change how multiple devices are authenticated on the port, but it does not affect whether a guest VLAN can be used. 'Multi-domain' restricts the port to one voice and one data device, while 'multi-host' allows any number of devices after a single successful authentication. Both host modes support a guest VLAN; the actual problem is that no guest VLAN has been configured with the 'authentication guest-vlan' command.
The port must be configured as a trunk port to allow the guest VLAN.
Why it fails: The guest VLAN is a single, untagged VLAN that the switch dynamically assigns to an access port when authentication fails; it is not a trunk VLAN. Trunk ports are designed to carry multiple VLANs with tagging, which would introduce unnecessary complexity and security risk for a guest access environment. A standard access port with 'authentication guest-vlan' is sufficient, and the command works regardless of the port's trunk or access mode—but using trunk would not solve the missing VLAN definition.
Trap 1: Weighted Random Early Detection (WRED)
Weighted Random Early Detection (WRED) is a congestion-avoidance mechanism that actively drops packets as queue depth crosses configured thresholds, preferentially marking or dropping lower-priority traffic to prevent TCP global synchronization. It is not a scheduling algorithm and has no concept of a priority queue or a dequeue order that can favor voice packets. In practice, WRED alone would still allow delay-sensitive packets to be dropped or queued arbitrarily, adding jitter and violating the strict latency requirement for real-time traffic.
Trap 2: Class-Based Weighted Fair Queuing (CBWFQ)
Class-Based Weighted Fair Queuing (CBWFQ) defines traffic classes and allocates each a guaranteed minimum bandwidth using weighted fair queuing within each class. However, it lacks a strict-priority queue: the scheduler serves classes based on configured weights and bandwidth, so a voice packet cannot be dequeued ahead of all remaining packets in lower-priority classes if its class is not the current user of the scheduler. Because latency and jitter are not bounded and no class gets absolute precedence, CBWFQ alone cannot deliver the lowest, predictable delay that interactive real-time traffic demands.
Trap 3: First-In, First-Out (FIFO)
First-In, First-Out (FIFO) places all packets in a single transmit queue and sends them in the exact order they arrive, meaning there is no mechanism to classify or prioritize interactive voice over bulk data. A single burst of file transfers or a greedy TCP stream can fill the queue, causing real-time packets to wait behind earlier arrivals and introducing variable delay and jitter. Consequently, FIFO offers no latency guarantee and is entirely unsuitable for low-latency real-time transport on a WAN link.
Low Latency Queuing (LLQ)
Low Latency Queuing (LLQ) is correct because it integrates a strict priority queue (PQ) with CBWFQ. The LLQ scheduler always empties the priority class before servicing any other CBWFQ class, which guarantees that real-time packets like voice are dequeued first and experience minimal, jitter-free delay. To prevent the PQ from starving other classes, LLQ applies a policer to priority-class traffic, dropping or shaping excess packets while still meeting the latency objective for admitted real-time flows.
Weighted Random Early Detection (WRED)
Why it fails: Weighted Random Early Detection (WRED) is a congestion-avoidance mechanism that actively drops packets as queue depth crosses configured thresholds, preferentially marking or dropping lower-priority traffic to prevent TCP global synchronization. It is not a scheduling algorithm and has no concept of a priority queue or a dequeue order that can favor voice packets. In practice, WRED alone would still allow delay-sensitive packets to be dropped or queued arbitrarily, adding jitter and violating the strict latency requirement for real-time traffic.
Class-Based Weighted Fair Queuing (CBWFQ)
Why it fails: Class-Based Weighted Fair Queuing (CBWFQ) defines traffic classes and allocates each a guaranteed minimum bandwidth using weighted fair queuing within each class. However, it lacks a strict-priority queue: the scheduler serves classes based on configured weights and bandwidth, so a voice packet cannot be dequeued ahead of all remaining packets in lower-priority classes if its class is not the current user of the scheduler. Because latency and jitter are not bounded and no class gets absolute precedence, CBWFQ alone cannot deliver the lowest, predictable delay that interactive real-time traffic demands.
First-In, First-Out (FIFO)
Why it fails: First-In, First-Out (FIFO) places all packets in a single transmit queue and sends them in the exact order they arrive, meaning there is no mechanism to classify or prioritize interactive voice over bulk data. A single burst of file transfers or a greedy TCP stream can fill the queue, causing real-time packets to wait behind earlier arrivals and introducing variable delay and jitter. Consequently, FIFO offers no latency guarantee and is entirely unsuitable for low-latency real-time transport on a WAN link.
Trap 1: The physical interface is configured with 'no ip address'.
The physical interface in a PPPoE configuration is intentionally left without an IP address. This interface operates at Layer 2 only and is used to encapsulate PPPoE frames via a dialer pool, while the dialer interface carries all Layer 3 addressing. IPCP assigns the IP address to the dialer interface, not to the physical Ethernet port. Therefore, seeing 'no ip address' on the physical interface is both expected and correct, and it is not the cause of the connectivity failure.
Trap 2: The default route is pointing to the wrong next-hop IP.
A default route in a PPPoE environment is typically configured with the dialer interface as the egress, using the form 'ip route 0.0.0.0 0.0.0.0 dialer 0' rather than a concrete next-hop IP. If the default route points to a specific next-hop IP, that IP would normally be the ISP gateway IP assigned during IPCP. However, because the dialer interface lacks an IP address, IPCP has not provided that next-hop value, and even a correctly pointed route cannot function. Thus the issue is not the route's target, but the missing IPCP address that makes any route unusable.
Trap 3: The ISP's gateway is not responding to ICMP.
While an unresponsive gateway could cause symptoms like this, it is not the root cause when the PPPoE session is already up. A PPPoE session being established confirms that the Ethernet link, PPP authentication, and LCP negotiation have succeeded, but ICMP requires IP-level routing and addressing. If the dialer interface has no IP address, the router cannot generate an ICMP echo request, so the gateway's response (or lack thereof) is irrelevant. The gateway is not the problem; the router's own missing IP address prevents it from participating in IP communication.
The dialer interface does not have an IP address negotiated via IPCP.
The presence of an IP address on the dialer interface is fundamental to PPPoE operation. During PPPoE, the ISP assigns an IPv4 address through IPCP (IP Control Protocol) as part of the PPP negotiation. If the dialer interface lacks an IP address, the router cannot build a usable routing table entry for the default route, and all traffic destined for the Internet is dropped because there is no valid source address. Without this IPCP-assigned address, even though the PPPoE session is established at Layer 2, the router has no IP reachability to the ISP gateway.
The physical interface is configured with 'no ip address'.
Why it fails: The physical interface in a PPPoE configuration is intentionally left without an IP address. This interface operates at Layer 2 only and is used to encapsulate PPPoE frames via a dialer pool, while the dialer interface carries all Layer 3 addressing. IPCP assigns the IP address to the dialer interface, not to the physical Ethernet port. Therefore, seeing 'no ip address' on the physical interface is both expected and correct, and it is not the cause of the connectivity failure.
The default route is pointing to the wrong next-hop IP.
Why it fails: A default route in a PPPoE environment is typically configured with the dialer interface as the egress, using the form 'ip route 0.0.0.0 0.0.0.0 dialer 0' rather than a concrete next-hop IP. If the default route points to a specific next-hop IP, that IP would normally be the ISP gateway IP assigned during IPCP. However, because the dialer interface lacks an IP address, IPCP has not provided that next-hop value, and even a correctly pointed route cannot function. Thus the issue is not the route's target, but the missing IPCP address that makes any route unusable.
The ISP's gateway is not responding to ICMP.
Why it fails: While an unresponsive gateway could cause symptoms like this, it is not the root cause when the PPPoE session is already up. A PPPoE session being established confirms that the Ethernet link, PPP authentication, and LCP negotiation have succeeded, but ICMP requires IP-level routing and addressing. If the dialer interface has no IP address, the router cannot generate an ICMP echo request, so the gateway's response (or lack thereof) is irrelevant. The gateway is not the problem; the router's own missing IP address prevents it from participating in IP communication.
Trap 1: Check the output of 'show vlan id 10' to see if VLAN 10 is active…
The 'show vlan id 10' command displays VLAN information, such as ports and status, but it does not show VNI mapping or EVPN route advertisement. While VLAN-to-VNI mapping is necessary for VXLAN, this command does not verify EVPN control plane operations. The engineer should focus on EVPN-specific commands to troubleshoot route advertisement.
Trap 2: Check the output of 'show interface nve1' to verify that the NVE…
The 'show interface nve1' command provides status and statistics for the NVE interface, such as whether it is up and the source IP address. However, it does not show EVPN route advertisement or VNI-to-EVPN association. While it is useful for verifying the NVE interface state, it does not address the specific issue of EVPN route advertisement for a VNI.
Trap 3: Check the output of 'show nve vni' to see if the VNI is up and…
The 'show nve vni' command displays the status of VNIs and their mapping to VLANs, but it does not directly show EVPN route advertisement. While it can confirm that the VNI is up, it does not verify the EVPN control plane association. The engineer needs to check EVPN route advertisement specifically, so this command alone is insufficient.
Check the output of 'show bgp l2vpn evpn' to see if the VNI is advertised in the EVPN address family.
The 'show bgp l2vpn evpn' command displays the EVPN routes in the BGP table, including Type-2 and Type-3 routes for MAC and IMET. By checking this output, the engineer can verify whether the VNI is being advertised. If the VNI is not present, it indicates a configuration issue with the EVPN control plane, such as missing VNI configuration under the EVPN address family or BGP neighbor issues.
Check the output of 'show vlan id 10' to see if VLAN 10 is active and mapped to the VNI.
Why it fails: The 'show vlan id 10' command displays VLAN information, such as ports and status, but it does not show VNI mapping or EVPN route advertisement. While VLAN-to-VNI mapping is necessary for VXLAN, this command does not verify EVPN control plane operations. The engineer should focus on EVPN-specific commands to troubleshoot route advertisement.
Check the output of 'show interface nve1' to verify that the NVE interface is operational.
Why it fails: The 'show interface nve1' command provides status and statistics for the NVE interface, such as whether it is up and the source IP address. However, it does not show EVPN route advertisement or VNI-to-EVPN association. While it is useful for verifying the NVE interface state, it does not address the specific issue of EVPN route advertisement for a VNI.
Check the output of 'show nve vni' to see if the VNI is up and associated with the NVE interface.
Why it fails: The 'show nve vni' command displays the status of VNIs and their mapping to VLANs, but it does not directly show EVPN route advertisement. While it can confirm that the VNI is up, it does not verify the EVPN control plane association. The engineer needs to check EVPN route advertisement specifically, so this command alone is insufficient.
A network engineer runs the following command on Switch SW1:
SW1# show interfaces gi0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: trunk Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk Native VLAN tagging: enabled Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk private VLANs: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL
Based on this output, what can be concluded?
Trap 1: The interface is configured as an access port.
The show interfaces trunk output explicitly lists the Administrative Mode as 'trunk' and the Operational Mode as 'trunk', which directly contradicts the assertion that the interface is configured as an access port. An access port would have an administrative mode of 'static access' or 'dynamic auto' and would not appear in the trunk output. Therefore, this conclusion is unsupported by the command output.
Trap 2: The native VLAN is tagged with 802.1Q.
Actually, native VLAN tagging is enabled, meaning the native VLAN is tagged, but the statement is ambiguous. However, the correct interpretation is that native VLAN tagging is enabled, but the question asks what can be concluded. Option B is more directly supported.
Trap 3: All VLANs except 2-1001 are pruned.
The line 'Pruning VLANs Enabled: 2-1001' indicates that VLANs 2 through 1001 are eligible for pruning, meaning the switch may remove them from the trunk for load balancing if the neighbor does not use them. It does not state that these VLANs are actually being pruned, nor does it imply that all other VLANs are pruned. The phrasing 'except 2-1001 are pruned' inverts the correct meaning, confusing eligibility with active pruning.
The interface is configured as an access port.
Why it fails: The show interfaces trunk output explicitly lists the Administrative Mode as 'trunk' and the Operational Mode as 'trunk', which directly contradicts the assertion that the interface is configured as an access port. An access port would have an administrative mode of 'static access' or 'dynamic auto' and would not appear in the trunk output. Therefore, this conclusion is unsupported by the command output.
DTP is enabled on this interface.
The command output includes the line 'Negotiation of Trunking: On', which confirms that Dynamic Trunking Protocol (DTP) is enabled and actively attempting to negotiate trunking with the connected neighbor. DTP is a Cisco proprietary protocol that allows the interface to dynamically decide between access and trunk mode. This is the correct and directly supported conclusion from the provided switchport trunk information.
The native VLAN is tagged with 802.1Q.
Why it fails: Actually, native VLAN tagging is enabled, meaning the native VLAN is tagged, but the statement is ambiguous. However, the correct interpretation is that native VLAN tagging is enabled, but the question asks what can be concluded. Option B is more directly supported.
All VLANs except 2-1001 are pruned.
Why it fails: The line 'Pruning VLANs Enabled: 2-1001' indicates that VLANs 2 through 1001 are eligible for pruning, meaning the switch may remove them from the trunk for load balancing if the neighbor does not use them. It does not state that these VLANs are actually being pruned, nor does it imply that all other VLANs are pruned. The phrasing 'except 2-1001 are pruned' inverts the correct meaning, confusing eligibility with active pruning.
Trap 1: Change the video traffic marking to DSCP AF41 and rely on…
This is incorrect because, by default, Catalyst switches perform queue selection based on the CoS field, not the DSCP value, unless you explicitly configure 'mls qos trust dscp' and a DSCP-to-queue map (e.g., 'mls qos srr-queue output dscp-map'). Simply re-marking video to AF41 does not change the CoS-to-queue assignment, so video would still be placed in the same queue as voice if both have the same CoS or if the DSCP mapping is not defined. Furthermore, even with DSCP trust enabled, the default DSCP map might still not separate AF41 from voice, so an additional mapping change would still be required.
Trap 2: Apply a service policy that uses a priority queue for voice only
Applying a service policy that designates a strict priority queue for voice only does not address the underlying queue mapping problem. The priority command only dictates the scheduling behavior of the queue that voice is placed in; it does not alter which hardware queue video is mapped to. Since video remains in its default queue (which may be the same as voice if the CoS-to-queue mapping is unchanged), the two traffic classes will continue to share the same buffer and scheduling treatment. The correct approach is to remap the CoS values so that voice and video are assigned to different queues, then optionally apply priority scheduling to the voice queue.
Trap 3: Increase the number of queues to eight
Increasing the number of output queues to eight is impossible on most Catalyst switching platforms because the number of egress queues per port is fixed by the hardware and typically ranges from two to four, with some ASICs supporting more but not via a software command. Even on platforms that support eight queues, the real issue is that voice and video are currently colliding in the same queue due to the existing CoS-to-queue mapping. Merely adding queues provides no benefit unless the mapping is changed to direct the traffic into the new queues. There is no CLI command to alter the hardware queue count, so this option is not a valid solution.
Modify the CoS-to-queue mapping using the 'mls qos srr-queue output cos-map' command
This command is correct because on Catalyst switches the default queue assignment for output traffic is based on the CoS value in the 802.1Q header. By modifying the CoS-to-queue map, you can explicitly assign voice (typically CoS 5) to a strict-priority queue and video (e.g., CoS 4) to a separate standard queue, thereby preventing inter-class contention. The command takes precedence over any default mapping and gives the engineer deterministic control over which hardware queue each marked packet uses.
Change the video traffic marking to DSCP AF41 and rely on DSCP-to-queue mapping
Why it fails: This is incorrect because, by default, Catalyst switches perform queue selection based on the CoS field, not the DSCP value, unless you explicitly configure 'mls qos trust dscp' and a DSCP-to-queue map (e.g., 'mls qos srr-queue output dscp-map'). Simply re-marking video to AF41 does not change the CoS-to-queue assignment, so video would still be placed in the same queue as voice if both have the same CoS or if the DSCP mapping is not defined. Furthermore, even with DSCP trust enabled, the default DSCP map might still not separate AF41 from voice, so an additional mapping change would still be required.
Apply a service policy that uses a priority queue for voice only
Why it fails: Applying a service policy that designates a strict priority queue for voice only does not address the underlying queue mapping problem. The priority command only dictates the scheduling behavior of the queue that voice is placed in; it does not alter which hardware queue video is mapped to. Since video remains in its default queue (which may be the same as voice if the CoS-to-queue mapping is unchanged), the two traffic classes will continue to share the same buffer and scheduling treatment. The correct approach is to remap the CoS values so that voice and video are assigned to different queues, then optionally apply priority scheduling to the voice queue.
Increase the number of queues to eight
Why it fails: Increasing the number of output queues to eight is impossible on most Catalyst switching platforms because the number of egress queues per port is fixed by the hardware and typically ranges from two to four, with some ASICs supporting more but not via a software command. Even on platforms that support eight queues, the real issue is that voice and video are currently colliding in the same queue due to the existing CoS-to-queue mapping. Merely adding queues provides no benefit unless the mapping is changed to direct the traffic into the new queues. There is no CLI command to alter the hardware queue count, so this option is not a valid solution.
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.
Free account
Create a free account to save your results and see which topics improve across sessions.
Focused Python For Network Automation sessions
Every question in these sessions is drawn from the Python For Network Automation domain — nothing else.
Related practice questions
Move into related areas when this topic feels solid.
Sharpen your 350-401 knowledge of Architecture.
Practise 350-401 questions linked to Virtualization.
Work through 350-401 questions on Infrastructure.
Sharpen your 350-401 knowledge of Network Assurance.
Security practice questions for 350-401.
Targeted 350-401 practice covering 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.
Python For Network Automation only
Mixed 350-401 sessionA free account saves results across sessions and highlights which topics need work.
Sign up free