VLAN and Inter-VLAN Routing Scenarios

The destination session on the central switch is configured with 'monitor session 2 destination remote vlan 999' instead of 'monitor session 2 destination interface Gi1/0/1'.

Why it fails: The destination session on the RSPAN destination switch should use 'monitor session 2 source remote vlan 999' to receive mirrored frames from the RSPAN VLAN, combined with 'monitor session 2 destination interface Gi1/0/1' to send those frames to the local analyzer port. The command 'monitor session 2 destination remote vlan 999' shown in the option is actually the syntax used on the source switch to direct mirrored traffic into the RSPAN VLAN, not on the destination switch. Since the question explicitly states that the destination session is configured, this misconfiguration cannot be the missing piece; the failure must lie in the Layer 2 path between the switches.

The source sessions on the remote switches are configured with 'monitor session 1 source vlan 100' but the destination is not set to 'remote vlan 999'.

Why it fails: A valid RSPAN source session must include both a monitored source and an output destination of 'remote vlan 999' — for example, 'monitor session 1 source vlan 100' followed by 'monitor session 1 destination remote vlan 999'. Without the destination remote clause, the session would not inject mirrored frames into the RSPAN VLAN and would instead behave as a local SPAN session. However, the question states that the source sessions are already configured, implying they have the required destination remote configuration. Therefore, the missing piece is not an incomplete source session but rather the trunk allowed list on the link connecting the source switches to the central switch.

The RSPAN VLAN is not created as a remote SPAN VLAN; it must be configured with 'remote-span' command.

Why it fails: Incorrect; the 'remote-span' command is used on the VLAN to designate it as an RSPAN VLAN, but the question says the VLAN is active, implying it is configured. However, this is a common missing step, but the most likely missing configuration is the trunk allowance.

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.

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.

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.

All ports shown are in trunk mode.

Why it fails: Trunk ports would appear in 'show interfaces trunk' or be listed with 'trunk' in 'show vlan brief' (some IOS versions show trunk ports as 'trunk' in the Ports column). Here, only access ports are listed.

VLANs 1002-1005 are active and supported.

Why it fails: The VLANs 1002–1005 are shown in the 'act/unsup' state, meaning they are active but unsupported on this hardware platform. These are reserved FDDI and Token Ring VLANs, and the 'unsup' status indicates the switch cannot actually process them for user data forwarding. Therefore, the claim that they are both active and supported is false; their being active in the VLAN database does not imply they are operationally supported.

VLAN 20 has no ports assigned.

Why it fails: VLAN 20 is not without ports because the Ports column for VLAN 20 explicitly shows Gi0/6 and Gi0/7 assigned. The statement that VLAN 20 has no ports assigned misreads the output, which lists those two interfaces as active access members in that VLAN. Since interfaces Gi0/6 and Gi0/7 appear under VLAN 20, this option is incorrect.

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.

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.

ip address 192.168.1.1 255.255.255.0

Why it fails: This command assigns an IP address to the current interface, but it must be executed within an interface configuration mode. Without first entering 'interface vlan 1', this command would be invalid in global configuration mode. It is a necessary step after entering the SVI, but not the command to enter that mode.

interface fastethernet 0/1

Why it fails: This command enters the configuration mode for a physical FastEthernet port, not a VLAN interface. Physical interfaces are used for connecting devices and can be assigned to VLANs, but they do not directly provide management access for a specific VLAN unless configured as routed ports. The scenario requires assigning an IP address to VLAN 1, which is done via an SVI, not a physical interface.

vlan 1

Why it fails: The command 'vlan 1' in global configuration mode creates or modifies the VLAN itself, but it does not allow IP address assignment. It is used to name the VLAN or configure other VLAN parameters, but not for Layer 3 configuration. To assign an IP address, you must enter the SVI configuration with 'interface vlan 1'.

The EtherChannel will drop all untagged frames because the native VLAN is not in the allowed list.

Why it fails: The native VLAN is the VLAN assigned to untagged frames on an 802.1Q trunk, and it does not need to be listed in the allowed VLAN list for those frames to be forwarded. The EtherChannel will not drop untagged frames merely because the native VLAN is absent from the allowed list; instead, untagged traffic is associated with the configured native VLAN. A mismatch between the allowed list and the native VLAN would only affect tagged traffic in that VLAN, not untagged frames.

The EtherChannel will not form because the native VLAN must be the same across all interfaces, which it is.

Why it fails: The statement is incorrect because the native VLAN on all interfaces is already consistent (VLAN 999), which satisfies the requirement for forming an EtherChannel. The native VLAN does need to match across all member links, but since it does match, the EtherChannel will form normally. Merely having a consistent native VLAN is a prerequisite, not a barrier, so the claim that the channel will not form is false.

The EtherChannel will form but the native VLAN will be ignored on the port-channel.

Why it fails: The port-channel does not ignore the native VLAN; instead, it inherits the native VLAN configuration from the physical member interfaces when the logical interface is created. Once the EtherChannel is operational, the port-channel uses VLAN 999 as its native VLAN, so any untagged frames arriving on the port-channel are associated with that VLAN. The native VLAN is fully functional on the port-channel and must be the same on both sides of the channel to prevent traffic misclassification.

All WLANs are currently active and serving clients.

Why it fails: The IoT WLAN shows Status Disabled, so it is not serving clients; only three of the four WLANs are active. Assuming every listed WLAN is operational is tempting because the summary lists all configured entries, but the Status column distinguishes enabled from disabled.

The Guest WLAN uses WPA2 security.

Why it fails: The Guest WLAN's Security column reads Open, so no WPA2 encryption is applied there; WPA2 appears only against Corporate, IoT and Management. Open is tempting because guest networks often use a captive portal, but that is a Layer 3 web-authentication overlay, not WPA2, and the output records the Layer 2 security type only.

The Management WLAN is on the guest-vlan interface.

Why it fails: The Management WLAN (ID 4) maps to mgmt-vlan, not guest-vlan, which belongs to the Guest WLAN. Reading across the wrong row is tempting because both are enabled WPA2 WLANs, but the Interface column pairs each SSID with its own VLAN.

Configure 'spanning-tree vlan vlan-list priority 0' on the access switch.

Why it fails: A priority of 0 is the lowest possible numeric bridge priority and therefore carries the highest election precedence, meaning the access switch would immediately be selected as root for the listed VLANs. This reverses the desired design, forcing traffic to traverse the access layer and creating an inefficient and potentially unstable forwarding path. In a network where multiple switches hold priority 0, the lowest MAC address decides the root, making the outcome unpredictable. Thus, while 0 is a legal value, using it here directly contradicts the goal of keeping the distribution layer as root.

Enable UplinkFast on the access switch to provide fast failover.

Why it fails: UplinkFast is a legacy proprietary mechanism that only accelerates failover for blocked root ports on access switches, not for general link outages in a Rapid PVST+ domain. Because 802.1w already performs fast convergence through synchronizing handshakes, enabling UplinkFast is redundant and can force the switch to behave inconsistently when both mechanisms are present. It also does not participate in root bridge election, so it would not prevent the access switch from becoming root. In modern Catalyst environments, UplinkFast is effectively obsolete and is automatically disabled when Rapid PVST is configured.

Enable PortFast on the trunk ports to speed up convergence.

Why it fails: PortFast is intended strictly for ports that connect to end hosts, immediately moving them to the forwarding state and bypassing listening and learning; applying it to a trunk that links to another switch suppresses STP on that segment entirely. This creates a serious loop risk because the trunk can forward BPDUs that the switch will ignore, leading to broadcast storms and MAC address flapping. Cisco does offer a 'spanning-tree portfast trunk' option, but that is for authenticated host connections (e.g., a host that requires a trunk), never for a normal switch-to-switch uplink. Since the access switch's trunk to the distribution switch is a switch-to-switch link, PortFast would be an unsafe and incorrect convergence shortcut.

The new switch is not configured with the same VLANs as the distribution switches.

Why it fails: A lack of identical VLAN configurations does not create loops; instead, it causes per-VLAN connectivity failures because traffic for missing VLANs is simply not forwarded. The switch can still run STP and maintain a loop-free topology for the VLANs it does carry. The described symptoms of broadcast storms and severe degradation are not consistent with a simple VLAN mismatch, which would affect only specific VLAN traffic.

The new switch has a lower bridge priority than the current root bridge.

Why it fails: Setting a lower bridge priority makes the new switch more eligible to become the root bridge, but STP still ensures a loop-free environment regardless of which switch is root. The root bridge is a legitimate role, and changing it merely alters the topology paths, causing some traffic to take different routes. It would not by itself generate the broadcast storms or MAC flapping indicative of a Layer 2 loop, so this is not the cause.

The new switch has become the root bridge and is sending inferior BPDUs.

Why it fails: The root bridge does not send inferior BPDUs; it sends superior BPDUs with a higher priority that other switches accept as the best. Becoming the root bridge is a normal condition and does not inherently create loops. This option is incorrect because it both mischaracterizes BPDU behavior and confuses a topology change with a loop, which is the actual cause.

The port connected to the DHCP server should be untrusted for DAI to work correctly.

Why it fails: The DHCP server port must be configured as trusted, not untrusted, for DAI to operate correctly. DAI does not inspect ARP packets that arrive on trusted ports; an untrusted DHCP server port would cause DAI to drop the server's ARP messages, breaking DHCP and subsequent security verification.

The DHCP server is in a different VLAN, and DAI cannot validate cross-VLAN ARP.

Why it fails: DAI inspects ARP packets on a per-VLAN basis using the DHCP snooping binding table, which contains entries for multiple VLANs. The location of the DHCP server is irrelevant because its port is trusted and its ARP traffic is exempt from inspection; only the hosts' ARP messages are validated against their own VLAN's bindings.

DAI is checking the destination MAC address, which does not match the expected value.

Why it fails: DAI does not validate the destination MAC address in an Ethernet or ARP frame. Instead, it validates the sender hardware address and sender protocol address against the DHCP snooping binding table, then checks the frame's source MAC address. The destination is irrelevant to the binding check; DAI only cares who is speaking, not to whom the packet is directed.

MAB will be attempted first, and if it fails, 802.1X will be used.

Why it fails: This option reverses the default order. On a port with both 802.1X and MAB enabled, the authenticator state machine always begins with EAPOL-Request/Identity frames to detect an 802.1X-capable supplicant. Only after the EAPOL timeout expires with no response does the switch trigger MAB, which then sends a RADIUS Access-Request using the source MAC address as the identity. MAB is explicitly a fallback for non-802.1X devices, never the first method.

The port will be placed in a guest VLAN if both 802.1X and MAB fail.

Why it fails: A guest VLAN is not automatically applied when both 802.1X and MAB fail. It must be explicitly configured on the interface using commands such as dot1x guest-vlan or authentication event fail action authorize vlan. In the absence of such a configuration, a port that fails both methods remains in the unauthorized state (or continues with the default security behavior), rather than being placed into any particular VLAN. Therefore this option describes a possible action only if a guest VLAN were configured, which is not the case here.

The switch will act as a supplicant for MAB and an authenticator for 802.1X.

Why it fails: The switch never acts as a supplicant for MAB or 802.1X in this scenario. In both methods the switch is the authenticator: for 802.1X it enforces EAPOL exchanges, and for MAB it sends a RADIUS Access-Request on behalf of the connecting device. The supplicant role belongs to the endpoint, such as a PC running a supplicant or any device whose MAC address is presented for MAB. Confusing these roles is incorrect and would misunderstand the control-plane direction: the switch authenticates the client, not the other way around.

The RADIUS server is not sending the correct VLAN ID in the Access-Accept.

Why it fails: This is incorrect because the symptom is that client devices receive an IP address in VLAN 100 and can associate, but cannot reach resources beyond the access switch. If the RADIUS server were sending an incorrect VLAN ID, the clients would either be placed in a different VLAN than intended (e.g., a guest VLAN) or authentication would fail outright. The problem is not on the RADIUS side; the Access-Accept is valid and correctly specifies VLAN 100 for the wireless clients.

The WLC is not configured for 802.1X on the uplink to the switch.

Why it fails: This is incorrect because 802.1X is a port-based access control method designed for point-to-point links and is not used on the uplink between a WLC and a switch. The WLC-to-switch link is normally configured as a trunk or an access port carrying multiple or a single VLAN, and it should not run 802.1X. Even if 802.1X were misconfigured on the uplink, it would not affect the drop of tagged VLAN 100 frames, because the issue is with VLAN pruning, not with port authentication.

The users' devices are not configured for MAB.

Why it fails: This is incorrect because MAB (MAC Authentication Bypass) is a fallback mechanism for devices that do not support 802.1X supplicants, such as printers or legacy devices. Wireless clients using 802.1X authenticate via the WLC, which acts as the authenticator (or passes EAP frames to the RADIUS server), and they do not require MAB. The problem described is about VLAN tagging on the trunk, not about the inability of the clients to perform 802.1X; MAB is irrelevant and would be a redundant fallback on the WLC, not a client-side setting.