350-401 · topic practice
Practise 350-401 VLAN and trunking questions covering access ports, trunk ports, allowed VLAN lists, native VLAN, inter-VLAN routing, and command-output troubleshooting.
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
Why learners struggle
VLAN questions are commonly missed because learners assume a VLAN configured on one switch exists everywhere, or that a trunk being active means all VLANs are allowed. The real problem is usually in the details: VLAN membership, allowed VLAN lists, native VLAN, or inter-VLAN routing setup.
Watch out for
Practice set
20 questions · select your answer, then reveal the explanation
Drag or tap steps into the slots.
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.
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.
Consider this VLAN configuration on a Cisco switch:
vlan 10
name Sales
vlan 20
name Engineering
interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 10,20
What is missing if the switch needs to carry VLAN 30 traffic on this trunk?
Trap 1: The trunk must be configured as an access port for VLAN 30.
Configuring the interface as an access port forces it to carry exactly one untagged VLAN, typically the native VLAN, and it strips 802.1Q tags from all frames. That would break the fabric's need to transport multiple VLANs with tags intact, so VLAN 30 could not be forwarded across the link alongside other VLANs. An access port cannot serve as a multi-VLAN trunk in SD-Access, and it would also disrupt the VXLAN/VLAN mapping at the edge.
Trap 2: The native VLAN must be changed to VLAN 30.
Changing the native VLAN to VLAN 30 only alters which VLAN is carried untagged on the trunk; it does not add VLAN 30 to the allowed list nor make it available for tagged traffic. Additionally, native VLAN mismatch can trigger CDP errors and spanning-tree inconsistences, but even a perfectly matched native VLAN does not permit other VLANs to traverse the link. The correct fix is to create VLAN 30 and add it to the allowed list, not to shift the native VLAN.
Trap 3: The switchport mode must be changed to dynamic desirable.
Switching the trunk mode to dynamic desirable invokes DTP to negotiate the link mode, but DTP does not influence which VLANs are permitted on the trunk or what exists in the VLAN database. The interface is already operating as a trunk, so the problem is not negotiation but the absence of VLAN 30 from the allowed list and local VLAN database. In fact, dynamic desirable can cause the link to become an access port if the peer is set to dynamic auto or does not respond, making the issue worse.
VLAN 30 must be created and added to the allowed VLAN list on the trunk.
On an 802.1Q trunk, each VLAN must first exist in the switch's local VLAN database and then be explicitly included in the allowed VLAN list on the trunk interface. Without both steps, the switch filters frames for VLAN 30, even if the VLAN is defined elsewhere in the SD-Access fabric. The edge node must have a consistent local VLAN-to-SGT mapping, and traffic will be dropped in hardware if the VLAN is not present and permitted.
The trunk must be configured as an access port for VLAN 30.
Why it fails: Configuring the interface as an access port forces it to carry exactly one untagged VLAN, typically the native VLAN, and it strips 802.1Q tags from all frames. That would break the fabric's need to transport multiple VLANs with tags intact, so VLAN 30 could not be forwarded across the link alongside other VLANs. An access port cannot serve as a multi-VLAN trunk in SD-Access, and it would also disrupt the VXLAN/VLAN mapping at the edge.
The native VLAN must be changed to VLAN 30.
Why it fails: Changing the native VLAN to VLAN 30 only alters which VLAN is carried untagged on the trunk; it does not add VLAN 30 to the allowed list nor make it available for tagged traffic. Additionally, native VLAN mismatch can trigger CDP errors and spanning-tree inconsistences, but even a perfectly matched native VLAN does not permit other VLANs to traverse the link. The correct fix is to create VLAN 30 and add it to the allowed list, not to shift the native VLAN.
The switchport mode must be changed to dynamic desirable.
Why it fails: Switching the trunk mode to dynamic desirable invokes DTP to negotiate the link mode, but DTP does not influence which VLANs are permitted on the trunk or what exists in the VLAN database. The interface is already operating as a trunk, so the problem is not negotiation but the absence of VLAN 30 from the allowed list and local VLAN database. In fact, dynamic desirable can cause the link to become an access port if the peer is set to dynamic auto or does not respond, making the issue worse.
Trap 1: Application-aware routing policies
Application-aware routing policies control path selection based on application performance, but they do not provide traffic segmentation. They are used to steer traffic based on SLA, not to isolate segments. While they can be applied per VPN, they are not the component that creates the segmentation itself. The question asks for components used to achieve segmentation, not policy enforcement.
Trap 2: IPsec tunnels between branches
IPsec tunnels provide secure transport between branches, but they do not inherently provide segmentation. All segments can share the same IPsec tunnels, with segmentation enforced via VPN segments and VRFs. IPsec ensures confidentiality and integrity, but without VPN segmentation, traffic from different segments would mix. Therefore, IPsec tunnels alone do not achieve the required isolation.
Trap 3: VLANs on the WAN Edge routers
VLANs on WAN Edge routers are used for local LAN segmentation, but they do not provide end-to-end segmentation across the SD-WAN fabric. VLANs are Layer 2 constructs and are not carried across the overlay. While they can map to VPN segments, they alone do not achieve the required isolation and policy enforcement across all branches. They are a local mechanism, not a fabric-wide segmentation solution.
VPN segments in vManage
VPN segments in vManage allow the creation of separate virtual private networks (VPNs) within the SD-WAN overlay. Each segment has its own routing table and can be assigned to different VRFs on the WAN Edge devices. This provides isolation between guest, employee, and IoT traffic. Policies can be applied per VPN segment, enabling granular control. This is a core mechanism for segmentation in Cisco SD-WAN.
Application-aware routing policies
Why it fails: Application-aware routing policies control path selection based on application performance, but they do not provide traffic segmentation. They are used to steer traffic based on SLA, not to isolate segments. While they can be applied per VPN, they are not the component that creates the segmentation itself. The question asks for components used to achieve segmentation, not policy enforcement.
VRF instances on WAN Edge devices
VRF instances on WAN Edge devices are used to instantiate VPN segments. Each VPN segment maps to a VRF, which maintains a separate routing table and forwarding instance. This ensures that traffic from different segments is isolated. The VRF is the actual implementation of the segmentation on the device, working in conjunction with vManage to distribute the configuration. This is a correct component for achieving segmentation.
IPsec tunnels between branches
Why it fails: IPsec tunnels provide secure transport between branches, but they do not inherently provide segmentation. All segments can share the same IPsec tunnels, with segmentation enforced via VPN segments and VRFs. IPsec ensures confidentiality and integrity, but without VPN segmentation, traffic from different segments would mix. Therefore, IPsec tunnels alone do not achieve the required isolation.
VLANs on the WAN Edge routers
Why it fails: VLANs on WAN Edge routers are used for local LAN segmentation, but they do not provide end-to-end segmentation across the SD-WAN fabric. VLANs are Layer 2 constructs and are not carried across the overlay. While they can map to VPN segments, they alone do not achieve the required isolation and policy enforcement across all branches. They are a local mechanism, not a fabric-wide segmentation solution.
Trap 1: VTP pruning has removed VLAN 10 from the trunk.
VTP pruning would remove VLAN 10 from the trunk's allowed list only when no active access port exists for that VLAN on the downstream switch, and this would be visible with show interface trunk. If VLAN 10 still appears in the allowed list on the trunk, pruning has not occurred; the failure is due to the VLAN not being defined in the VLAN database on one switch. VTP pruning cannot remove a VLAN from the database itself—it only controls which VLANs are permitted on specific trunk links.
Trap 2: The native VLAN is mismatched.
A native VLAN mismatch appears on an 802.1Q trunk when the two ends are configured with different untagged VLAN IDs. This condition triggers CDP error messages and can put the trunk into an inconsistent state, but it affects only untagged traffic on the native VLAN, not a tagged VLAN such as VLAN 10. Since the problem is specific to VLAN 10 and other VLANs are presumably passing, native VLAN mismatch is not a valid explanation.
Trap 3: Spanning Tree Protocol is blocking VLAN 10 on the trunk.
While STP can block a VLAN on a trunk in PVST+ or Rapid PVST+, it does so only when a loop or redundant path exists for that VLAN. A single trunk link without an alternative path is not placed in a blocking state for one VLAN, and the port would remain forwarding for all other VLANs. Additionally, STP blocking would not hide a missing VLAN database entry—it would still show VLAN 10 as defined but in a discarding state, which is not the situation described.
VLAN 10 is not created in the VLAN database on one of the switches.
VLAN 10 must exist in the local VLAN database on both switches before traffic can cross an 802.1Q trunk. If one switch lacks VLAN 10, that switch will not forward tagged frames for that VLAN, even though the trunk interface is administratively up and the VLAN is in the allowed list. The switch will not create the VLAN dynamically unless VTP is in server mode and advertises it, so the missing database entry is the root cause.
VTP pruning has removed VLAN 10 from the trunk.
Why it fails: VTP pruning would remove VLAN 10 from the trunk's allowed list only when no active access port exists for that VLAN on the downstream switch, and this would be visible with show interface trunk. If VLAN 10 still appears in the allowed list on the trunk, pruning has not occurred; the failure is due to the VLAN not being defined in the VLAN database on one switch. VTP pruning cannot remove a VLAN from the database itself—it only controls which VLANs are permitted on specific trunk links.
The native VLAN is mismatched.
Why it fails: A native VLAN mismatch appears on an 802.1Q trunk when the two ends are configured with different untagged VLAN IDs. This condition triggers CDP error messages and can put the trunk into an inconsistent state, but it affects only untagged traffic on the native VLAN, not a tagged VLAN such as VLAN 10. Since the problem is specific to VLAN 10 and other VLANs are presumably passing, native VLAN mismatch is not a valid explanation.
Spanning Tree Protocol is blocking VLAN 10 on the trunk.
Why it fails: While STP can block a VLAN on a trunk in PVST+ or Rapid PVST+, it does so only when a loop or redundant path exists for that VLAN. A single trunk link without an alternative path is not placed in a blocking state for one VLAN, and the port would remain forwarding for all other VLANs. Additionally, STP blocking would not hide a missing VLAN database entry—it would still show VLAN 10 as defined but in a discarding state, which is not the situation described.
Drag or tap steps into the slots.
Drag or tap steps into the slots.
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.
Trap 1: Use the same VLAN for all tenants and rely on VLAN ACLs.
VLAN ACLs operate at Layer 2 and filter traffic within a broadcast domain; they cannot maintain separate routing tables or forwarding decisions per tenant. If all tenants share the same VLAN, their IP subnets and MAC addresses are visible to one another at the data-link layer, and VACLs cannot prevent ARP spoofing or other L2 attacks. Moreover, VACLs cannot resolve overlapping IP address spaces because they rely on a single L3 forwarding context, so the isolation required for multi-tenancy is fundamentally unavailable.
Trap 2: Configure static routes on each switch pointing to the next-hop IP…
Static routes placed in the global routing table are unaware of VRFs and cannot direct traffic that arrives on a VRF-aware interface. Even if the route points to a valid next hop in the global table, packets from a VRF will be dropped because the VRF's routing table has no corresponding route or because the next hop is not reachable from that VRF's context. Additionally, with overlapping subscriber addresses, a single global route is ambiguous and cannot select the correct egress interface. The fix would be to define separate static routes inside each VRF, not in the global table.
Trap 3: Enable OSPF with a single area on all switches and redistribute…
OSPF running in a single area without VRF-aware configuration builds one LSDB and one SPF tree for the entire device, so it cannot distinguish tenant A's routes from tenant B's routes. Redistribution between VRFs is not a native OSPF feature; it requires route leaking between VRFs, which violates the isolation VRFs are meant to enforce and can cause routing loops if not carefully filtered. Furthermore, OSPF's router ID and neighbor relationships are global by default, so you cannot run multiple independent OSPF instances for each tenant without enabling VRF-lite (per-VRF OSPF process). Therefore, a single-area OSPF approach cannot provide the per-tenant segregation this multi-tenant network demands.
Use the same VLAN for all tenants and rely on VLAN ACLs.
Why it fails: VLAN ACLs operate at Layer 2 and filter traffic within a broadcast domain; they cannot maintain separate routing tables or forwarding decisions per tenant. If all tenants share the same VLAN, their IP subnets and MAC addresses are visible to one another at the data-link layer, and VACLs cannot prevent ARP spoofing or other L2 attacks. Moreover, VACLs cannot resolve overlapping IP address spaces because they rely on a single L3 forwarding context, so the isolation required for multi-tenancy is fundamentally unavailable.
Create trunk links with 802.1Q subinterfaces on each switch and assign each subinterface to the appropriate VRF.
Creating an 802.1Q trunk with subinterfaces lets each switch or router terminate multiple VLANs on a single physical link, and each subinterface can be explicitly bound to a tenant's VRF. This gives each tenant an isolated routing table; the switch will route packets received on a subinterface using only the routes in that subinterface's assigned VRF. The trunk carries tagged frames for all tenants, but the VRF association ensures that traffic from tenant A's VLAN never enters tenant B's routing path, even though they share the same physical ports and trunk. This is a standard VRF-lite design for inter-switch VRF connectivity.
Configure static routes on each switch pointing to the next-hop IP in the global routing table.
Why it fails: Static routes placed in the global routing table are unaware of VRFs and cannot direct traffic that arrives on a VRF-aware interface. Even if the route points to a valid next hop in the global table, packets from a VRF will be dropped because the VRF's routing table has no corresponding route or because the next hop is not reachable from that VRF's context. Additionally, with overlapping subscriber addresses, a single global route is ambiguous and cannot select the correct egress interface. The fix would be to define separate static routes inside each VRF, not in the global table.
Enable OSPF with a single area on all switches and redistribute between VRFs.
Why it fails: OSPF running in a single area without VRF-aware configuration builds one LSDB and one SPF tree for the entire device, so it cannot distinguish tenant A's routes from tenant B's routes. Redistribution between VRFs is not a native OSPF feature; it requires route leaking between VRFs, which violates the isolation VRFs are meant to enforce and can cause routing loops if not carefully filtered. Furthermore, OSPF's router ID and neighbor relationships are global by default, so you cannot run multiple independent OSPF instances for each tenant without enabling VRF-lite (per-VRF OSPF process). Therefore, a single-area OSPF approach cannot provide the per-tenant segregation this multi-tenant network demands.
Drag or tap steps into the slots.
Trap 1: The trunk is not allowing VLAN 20 or VLAN 30.
The engineer already verified that the trunk allows VLAN 20 and VLAN 30, so this cannot be the fault. If the trunk were pruning or blocking these VLANs, the access switch would not deliver frames from those VLANs to the distribution switch at all, causing a complete loss of inter-VLAN connectivity. Since the trunk is operationally up and both VLANs are in the allowed list, the failure is not at the Layer 2 trunking layer.
Trap 2: Spanning Tree Protocol is blocking the SVI interfaces.
Spanning Tree Protocol operates only on physical and logical Layer 2 switch ports, never on Layer 3 SVIs. An SVI is a routed interface that exists in software and is not subject to STP's blocking or forwarding states. Even if a physical access port were blocked by STP, the SVI itself remains up, so STP cannot be responsible for the hosts' inability to reach their default gateway.
Trap 3: The native VLAN mismatch on the trunk is causing the issue.
A native VLAN mismatch on a trunk does not affect tagged VLAN frames like those on VLAN 20 and 30, because native VLAN traffic is sent untagged. The trunk is already up and passing the required VLANs, meaning the native VLAN is configured consistently (otherwise CDP or STP would flag an inconsistency). Therefore, a native VLAN mismatch is not the root cause of the inter-VLAN routing failure.
The hosts are not configured with the correct default gateway pointing to the SVI on the distribution switch.
The hosts cannot reach the SVI because their default gateway is either absent or set to an incorrect IP address. For inter-VLAN communication, each host must send Layer 3 packets to its VLAN's SVI IP, which then routes them to other VLANs. If the gateway points to the wrong address (e.g., another host or a nonexistent IP), frames are sent to the wrong destination and never reach the distribution switch's routing engine.
The trunk is not allowing VLAN 20 or VLAN 30.
Why it fails: The engineer already verified that the trunk allows VLAN 20 and VLAN 30, so this cannot be the fault. If the trunk were pruning or blocking these VLANs, the access switch would not deliver frames from those VLANs to the distribution switch at all, causing a complete loss of inter-VLAN connectivity. Since the trunk is operationally up and both VLANs are in the allowed list, the failure is not at the Layer 2 trunking layer.
Spanning Tree Protocol is blocking the SVI interfaces.
Why it fails: Spanning Tree Protocol operates only on physical and logical Layer 2 switch ports, never on Layer 3 SVIs. An SVI is a routed interface that exists in software and is not subject to STP's blocking or forwarding states. Even if a physical access port were blocked by STP, the SVI itself remains up, so STP cannot be responsible for the hosts' inability to reach their default gateway.
The native VLAN mismatch on the trunk is causing the issue.
Why it fails: A native VLAN mismatch on a trunk does not affect tagged VLAN frames like those on VLAN 20 and 30, because native VLAN traffic is sent untagged. The trunk is already up and passing the required VLANs, meaning the native VLAN is configured consistently (otherwise CDP or STP would flag an inconsistency). Therefore, a native VLAN mismatch is not the root cause of the inter-VLAN routing failure.
Trap 1: aaa authentication dot1x default group radius
The command 'aaa authentication dot1x default group radius' specifies the authentication method list for 802.1X, directing authentication requests to a RADIUS server group. While this command is necessary for 802.1X to work with RADIUS, it does not globally enable 802.1X on the switch. It must be used in conjunction with 'dot1x system-auth-control'. Alone, it does not activate 802.1X authentication.
Trap 2: authentication port-control auto
The command 'authentication port-control auto' is an interface-level command that enables 802.1X authentication on a specific port. It does not enable 802.1X globally. It is used after global configuration and specifies that the port will use 802.1X authentication. Without the global command, this interface command alone will not enable 802.1X. Thus, it is not the correct answer for global enablement.
Trap 3: dot1x pae authenticator
The command 'dot1x pae authenticator' is configured on an interface to set the Port Access Entity (PAE) role as the authenticator. It is an interface-level command, not a global command. While it is part of 802.1X configuration, it does not enable 802.1X globally. The global command 'dot1x system-auth-control' is required first. Therefore, this option is not correct for enabling 802.1X globally.
aaa authentication dot1x default group radius
Why it fails: The command 'aaa authentication dot1x default group radius' specifies the authentication method list for 802.1X, directing authentication requests to a RADIUS server group. While this command is necessary for 802.1X to work with RADIUS, it does not globally enable 802.1X on the switch. It must be used in conjunction with 'dot1x system-auth-control'. Alone, it does not activate 802.1X authentication.
dot1x system-auth-control
The command 'dot1x system-auth-control' enables 802.1X authentication globally on a Cisco switch. It is a prerequisite for configuring 802.1X on individual interfaces. Without this command, 802.1X authentication will not function, even if interface-level commands are configured. This command allows the switch to act as an authenticator and communicate with the RADIUS server to authenticate supplicants.
authentication port-control auto
Why it fails: The command 'authentication port-control auto' is an interface-level command that enables 802.1X authentication on a specific port. It does not enable 802.1X globally. It is used after global configuration and specifies that the port will use 802.1X authentication. Without the global command, this interface command alone will not enable 802.1X. Thus, it is not the correct answer for global enablement.
dot1x pae authenticator
Why it fails: The command 'dot1x pae authenticator' is configured on an interface to set the Port Access Entity (PAE) role as the authenticator. It is an interface-level command, not a global command. While it is part of 802.1X configuration, it does not enable 802.1X globally. The global command 'dot1x system-auth-control' is required first. Therefore, this option is not correct for enabling 802.1X globally.
Trap 1: Cisco StackWise Virtual on the distribution switches
StackWise Virtual combines two physical switches into one logical switch for control-plane and management simplification, but it does not decouple user identity from location or reduce VLAN and subnet provisioning across floors. Users still need VLANs and subnets tied to their access ports, so this does not satisfy the stated design requirement.
Trap 2: Cisco Software-Defined Access with traditional VLAN trunking to the…
Trunking VLANs to a wireless controller keeps the wireless traffic tied to physical VLAN and subnet boundaries, which is exactly the sprawl the design is trying to avoid. Although SD-Access is mentioned, pairing it with legacy VLAN trunking defeats the overlay model and does not provide location-independent identity or consistent policy across wired and wireless.
Trap 3: Cisco TrustSec with static SGACL enforcement on access ports
TrustSec provides group-based policy using security group tags, which addresses consistent policy, but it does not by itself eliminate VLAN and subnet sprawl or unify wired and wireless access into one logical segment. Without an overlay fabric, the branch still requires separate VLANs and subnets for each floor, so it only partially meets the requirement.
Cisco StackWise Virtual on the distribution switches
Why it fails: StackWise Virtual combines two physical switches into one logical switch for control-plane and management simplification, but it does not decouple user identity from location or reduce VLAN and subnet provisioning across floors. Users still need VLANs and subnets tied to their access ports, so this does not satisfy the stated design requirement.
Cisco Software-Defined Access with traditional VLAN trunking to the WLC
Why it fails: Trunking VLANs to a wireless controller keeps the wireless traffic tied to physical VLAN and subnet boundaries, which is exactly the sprawl the design is trying to avoid. Although SD-Access is mentioned, pairing it with legacy VLAN trunking defeats the overlay model and does not provide location-independent identity or consistent policy across wired and wireless.
Cisco SD-Access fabric with VXLAN overlay and policy-based segmentation
SD-Access decouples identity from location by using a VXLAN overlay, so a user keeps the same IP subnet and security group tag whether wired or wireless. This eliminates per-floor VLAN/subnet sprawl and enforces consistent group-based policy through the fabric, which directly matches the stated requirement for unified wired/wireless policy with minimal VLAN provisioning.
Cisco TrustSec with static SGACL enforcement on access ports
Why it fails: TrustSec provides group-based policy using security group tags, which addresses consistent policy, but it does not by itself eliminate VLAN and subnet sprawl or unify wired and wireless access into one logical segment. Without an overlay fabric, the branch still requires separate VLANs and subnets for each floor, so it only partially meets the requirement.
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: IPsec tunnel established between the access switch and the Cisco…
IPsec tunnels encrypt traffic between endpoints but do not distribute role identity. DNA Center is a management platform and does not participate in TrustSec data-plane enforcement. This option confuses management-plane connectivity with the data-plane tagging mechanism TrustSec actually uses for role-based access control.
Trap 2: MACsec encryption applied on the uplink between access and…
MACsec provides hop-by-hop Layer 2 confidentiality and integrity, not role-based access enforcement. It encrypts frames but does not carry group membership, so it cannot enforce policy according to a device's role. Using MACsec alone would leave access decisions dependent on IP or MAC addresses, which fails the mobility requirement.
Trap 3: Cisco Identity Services Engine (ISE) profiling the endpoint after…
ISE profiling identifies device type and can assign an SGT through authorization, but profiling alone does not carry the role identity across the network. Without a tag or SXP propagation, downstream devices cannot enforce role-based policy consistently as endpoints move. Profiling is a supporting function, not the transport mechanism.
IPsec tunnel established between the access switch and the Cisco DNA Center appliance.
Why it fails: IPsec tunnels encrypt traffic between endpoints but do not distribute role identity. DNA Center is a management platform and does not participate in TrustSec data-plane enforcement. This option confuses management-plane connectivity with the data-plane tagging mechanism TrustSec actually uses for role-based access control.
Security Group Tag (SGT) applied at ingress and propagated via inline tagging or SXP.
The SGT is a 16-bit value inserted into the frame or packet at the ingress device, which then enforces policy at egress based on the tag instead of IP. Propagation via inline tagging or the SGT Exchange Protocol (SXP) keeps role identity intact across VLAN and subnet boundaries, which is exactly what the security team requires.
MACsec encryption applied on the uplink between access and distribution switches.
Why it fails: MACsec provides hop-by-hop Layer 2 confidentiality and integrity, not role-based access enforcement. It encrypts frames but does not carry group membership, so it cannot enforce policy according to a device's role. Using MACsec alone would leave access decisions dependent on IP or MAC addresses, which fails the mobility requirement.
Cisco Identity Services Engine (ISE) profiling the endpoint after DHCP and HTTP probes.
Why it fails: ISE profiling identifies device type and can assign an SGT through authorization, but profiling alone does not carry the role identity across the network. Without a tag or SXP propagation, downstream devices cannot enforce role-based policy consistently as endpoints move. Profiling is a supporting function, not the transport mechanism.
Drag or tap steps into the slots.
Trap 1: Configure the guest WLAN with AP group VLAN tagging and enable…
FlexConnect local switching terminates guest traffic at the branch access point rather than tunneling it to a DMZ interface on the WLC. This scenario explicitly requires guest traffic to be tunneled to a DMZ interface, so local switching at the AP would defeat the design. AP group VLAN tagging alone does not create a DMZ tunnel to the controller.
Trap 2: Configure the guest WLAN to use the management interface with a…
The management interface on an AireOS WLC is used for in-band management and for terminating CAPWAP tunnels. Placing guest traffic on the management interface exposes the controller to guest clients and does not provide isolation from corporate traffic. A separate SSID alone does not separate the traffic path or provide DMZ termination.
Trap 3: Configure the guest WLAN to use the virtual interface and enable…
The virtual interface on an AireOS WLC is an unconfigured, unroutable address used only to support web authentication redirects and DHCP relay for guest clients. It does not carry guest data traffic or provide a DMZ path. Enabling Web Auth alone does not isolate guest clients from internal corporate clients.
Configure the guest WLAN with AP group VLAN tagging and enable FlexConnect local switching.
Why it fails: FlexConnect local switching terminates guest traffic at the branch access point rather than tunneling it to a DMZ interface on the WLC. This scenario explicitly requires guest traffic to be tunneled to a DMZ interface, so local switching at the AP would defeat the design. AP group VLAN tagging alone does not create a DMZ tunnel to the controller.
Configure the guest WLAN to use the management interface with a separate SSID.
Why it fails: The management interface on an AireOS WLC is used for in-band management and for terminating CAPWAP tunnels. Placing guest traffic on the management interface exposes the controller to guest clients and does not provide isolation from corporate traffic. A separate SSID alone does not separate the traffic path or provide DMZ termination.
Configure the guest WLAN to use the virtual interface and enable Web Auth.
Why it fails: The virtual interface on an AireOS WLC is an unconfigured, unroutable address used only to support web authentication redirects and DHCP relay for guest clients. It does not carry guest data traffic or provide a DMZ path. Enabling Web Auth alone does not isolate guest clients from internal corporate clients.
Configure a dynamic interface mapped to the guest VLAN and assign it to the guest WLAN.
A dynamic interface on the AireOS WLC is a user-defined VLAN interface that maps a WLAN to a specific VLAN and is commonly placed on a DMZ segment for guest traffic. Assigning the guest WLAN to a dynamic interface isolates guest clients from corporate clients on the management interface and allows traffic to be tunneled to a firewall in the DMZ.
A network engineer runs the following command on Switch SW1:
SW1# show vlan id 10 VLAN ID: 10 VLAN Name: Sales VLAN Type: Ethernet VLAN State: active
MTU: 1500
Remote SPAN VLAN: No
Primary VLAN ID: 10
Private VLAN Type: Primary
Associated Secondary VLAN IDs: 100, 200
Based on this output, what can be concluded?
Trap 1: VLAN 10 is a community VLAN.
VLAN 10 cannot be a community VLAN because the output explicitly marks its Private VLAN Type as 'Primary' rather than 'Community.' In Cisco private VLAN terminology, a community VLAN is a secondary VLAN that allows hosts within the same community to communicate directly while still being isolated from other communities, and it is always associated with a primary VLAN. Since VLAN 10 is the primary itself, it is the parent VLAN that community and isolated secondary VLANs hang off of, not a community VLAN.
Trap 2: VLAN 10 is an isolated VLAN.
An isolated VLAN is also a secondary private VLAN type, but the output shows VLAN 10 as 'Primary,' which rules out this classification. Isolated VLANs permit only communication between their ports and a promiscuous port (typically a router or firewall), with no peer-to-peer traffic allowed between isolated ports. VLAN 10's role as a primary VLAN means it is the hub that connects the various secondary VLANs instead of being an isolated secondary. Therefore, this answer is incorrect.
Trap 3: VLAN 10 is a normal data VLAN with no private VLAN features.
The output clearly shows private VLAN configuration for VLAN 10, including a specific 'Private VLAN Type' and associated secondary VLAN fields, which would be absent on a normal data VLAN. A normal data VLAN operates as a simple broadcast domain with no promiscuous, community, or isolated port roles, whereas VLAN 10 is explicitly defined as a primary PVLAN with secondary mappings. Thus, stating it has no private VLAN features contradicts the very information shown in the exhibit.
VLAN 10 is a community VLAN.
Why it fails: VLAN 10 cannot be a community VLAN because the output explicitly marks its Private VLAN Type as 'Primary' rather than 'Community.' In Cisco private VLAN terminology, a community VLAN is a secondary VLAN that allows hosts within the same community to communicate directly while still being isolated from other communities, and it is always associated with a primary VLAN. Since VLAN 10 is the primary itself, it is the parent VLAN that community and isolated secondary VLANs hang off of, not a community VLAN.
VLAN 10 is an isolated VLAN.
Why it fails: An isolated VLAN is also a secondary private VLAN type, but the output shows VLAN 10 as 'Primary,' which rules out this classification. Isolated VLANs permit only communication between their ports and a promiscuous port (typically a router or firewall), with no peer-to-peer traffic allowed between isolated ports. VLAN 10's role as a primary VLAN means it is the hub that connects the various secondary VLANs instead of being an isolated secondary. Therefore, this answer is incorrect.
VLAN 10 is a primary private VLAN.
This is correct because the command output unambiguously lists 'Private VLAN Type: Primary' under VLAN 10's configuration, along with its associated secondary VLANs. A primary private VLAN is the root VLAN that carries upstream/downstream traffic and interconnects promiscuous ports with the secondary VLANs mapped to it. The presence of associated secondary VLAN fields confirms VLAN 10 is the primary in this private VLAN domain, making this the accurate description.
VLAN 10 is a normal data VLAN with no private VLAN features.
Why it fails: The output clearly shows private VLAN configuration for VLAN 10, including a specific 'Private VLAN Type' and associated secondary VLAN fields, which would be absent on a normal data VLAN. A normal data VLAN operates as a simple broadcast domain with no promiscuous, community, or isolated port roles, whereas VLAN 10 is explicitly defined as a primary PVLAN with secondary mappings. Thus, stating it has no private VLAN features contradicts the very information shown in the exhibit.
Trap 1: The standby switch is forwarding all broadcast traffic due to a…
A misconfigured STP root would alter the spanning-tree topology, potentially causing inefficient paths or even transient loops, but it does not force any single switch to forward 'all broadcast traffic.' Broadcast flooding is a normal behavior in every Layer 2 switch, and the root's position only affects the blocking/forwarding state of redundant links—not which switch processes broadcast frames. Sustained high CPU from broadcasts would be caused by a broadcast storm, which would broadly impact all switches, not specifically single out the standby in an HSRP pair.
Trap 2: The standby switch is performing routing for all VLANs because the…
If the active HSRP switch failed, the standby would transition to the Active state and begin actively routing/forwarding traffic for the affected VLANs, which could certainly increase CPU utilization. However, the scenario describes the standby switch as still being in the standby role, so it is not performing the routing function for all VLANs; it is merely exchanging hellos and monitoring for active failure. Therefore, this option misinterprets both the HSRP state machine and the cause of the reported CPU spikes.
Trap 3: The standby switch is processing VTP updates from the distribution…
VTP (VLAN Trunking Protocol) updates are only transmitted when a VLAN is added, removed, or modified, and they are not periodical; modern campus designs almost universally have VTP disabled or set to transparent mode. Even if VTP were active, the distribution layer would not be repeatedly sending updates that cause sustained CPU overhead solely on the standby switch—such a condition would require continuous configuration changes, which is not indicated. The periodic, per-VLAN HSRP hello load is a far more consistent and scalable explanation.
The standby switch is processing HSRP hellos for all VLANs, causing CPU spikes.
Each VLAN configured for HSRP creates a separate HSRP group, and the standby switch must process multicast hello packets (normally sent every 3 seconds) for every one of those groups. With hundreds of VLANs, the cumulative volume of hello packets—each requiring CPU interrupt handling, state-machine updates, and authentication checks—can saturate the control plane and manifest as CPU spikes. This makes HSRP hello processing the most plausible cause of standby CPU utilization in a large L3-access design.
The standby switch is forwarding all broadcast traffic due to a misconfigured STP root.
Why it fails: A misconfigured STP root would alter the spanning-tree topology, potentially causing inefficient paths or even transient loops, but it does not force any single switch to forward 'all broadcast traffic.' Broadcast flooding is a normal behavior in every Layer 2 switch, and the root's position only affects the blocking/forwarding state of redundant links—not which switch processes broadcast frames. Sustained high CPU from broadcasts would be caused by a broadcast storm, which would broadly impact all switches, not specifically single out the standby in an HSRP pair.
The standby switch is performing routing for all VLANs because the active switch failed.
Why it fails: If the active HSRP switch failed, the standby would transition to the Active state and begin actively routing/forwarding traffic for the affected VLANs, which could certainly increase CPU utilization. However, the scenario describes the standby switch as still being in the standby role, so it is not performing the routing function for all VLANs; it is merely exchanging hellos and monitoring for active failure. Therefore, this option misinterprets both the HSRP state machine and the cause of the reported CPU spikes.
The standby switch is processing VTP updates from the distribution layer.
Why it fails: VTP (VLAN Trunking Protocol) updates are only transmitted when a VLAN is added, removed, or modified, and they are not periodical; modern campus designs almost universally have VTP disabled or set to transparent mode. Even if VTP were active, the distribution layer would not be repeatedly sending updates that cause sustained CPU overhead solely on the standby switch—such a condition would require continuous configuration changes, which is not indicated. The periodic, per-VLAN HSRP hello load is a far more consistent and scalable explanation.
Free account
Create a free account to save your results and see which topics improve across sessions.
Focused Vlans And Trunking sessions
Every question in these sessions is drawn from the Vlans And Trunking 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