VLAN and Inter-VLAN Routing Scenarios

Change the port type of Gi0/3 to trunk to allow multiple VLANs.

Why wrong: Configuring Gi0/3 as a trunk only affects VLAN tagging and the set of VLANs carried, not the STP port role. The blocking state indicates an STP decision—likely that the current root bridge has a higher bridge priority than another switch for VLAN 10—so the port cannot forward even after trunk mode is set. Trunking would be relevant if VLANs were being pruned, but it cannot change the root bridge election or port cost calculations.

Configure spanning-tree portfast on Gi0/3 to speed up convergence.

Why wrong: Portfast is intended solely for access ports connected to end stations, allowing them to bypass the listening and learning states to converge quickly. Applying it to an inter-switch uplink like Gi0/3 is dangerous because it could create a temporary bridging loop during STP recalculation. Even if Portfast were enabled, the port would still block after the switch receives the superior BPDU that elected another switch as root; it only skips the forward-delay timers, not the STP decision itself.

Enable BPDU guard on Gi0/3 to prevent unauthorized switches from affecting the network.

Why wrong: BPDU guard is an STP protection feature typically enabled on PortFast-configured access ports; when it receives a BPDU, it disables the port to prevent rogue switches. On an uplink connecting two switches, BPDUs are expected and necessary for STP operation, so enabling BPDU guard would shut down Gi0/3 and disrupt the link entirely. It does nothing to influence root bridge selection or why Gi0/3 is in a blocking state, since that state is determined by root bridge priorities and path costs.

Check the DHCP server logs to see if it is receiving Discover messages.

Why wrong: Checking the DHCP server logs for Discover messages is premature in this scenario. Because the DHCP server resides on a different subnet than the clients, server-side logs will only show Discover packets if the router's VLAN 20 interface has an IP helper-address configured to forward broadcast DHCP requests. If the helper-address is missing, the router drops the broadcast at the VLAN boundary, and the server never sees any Discover traffic—so the absence of such messages in the logs would merely confirm the relay misconfiguration, not diagnose it. This step is valid only after confirming that the relay configuration is correct, and it wastes troubleshooting time by skipping the most fundamental cause.

Attempt to ping the DHCP server's IP address from the host's APIPA address.

Why wrong: The host's APIPA address (169.254.x.x) is a link-local address. Without a default gateway or a routable IP, pinging an address on a different subnet will not work, even if the DHCP server is reachable. This test does not confirm DHCP functionality and is not a standard troubleshooting step for DHCP failures.

Restart the DHCP service on the server and recheck the host.

Why wrong: Restarting the DHCP service is a disruptive action and should not be the first step, especially when the root cause likely lies in the network configuration (missing relay). It does not address the underlying issue and may cause unnecessary downtime.

The default gateway must be removed from the DHCP scope.

Why wrong: Removing the default gateway from the DHCP scope would eliminate the router as the next hop, breaking all off-subnet communication. The problem is isolated to hostname resolution while IP connectivity succeeds, so a missing gateway would cause total network failure, not just DNS failure. Therefore, the default gateway must remain in the scope and cannot be the cause.

The clients must use PPP before DNS works.

Why wrong: PPP (Point-to-Point Protocol) is a WAN data-link encapsulation used on serial or DSL links, not a service required for DNS on an Ethernet LAN. DNS resolution operates over IP and is independent of the data-link protocol; clients do not need PPP to send DNS queries. This option incorrectly conflates a WAN technology with local DHCP operation and is unrelated to the VLAN 70 issue.

The VLAN must be converted to the native VLAN on all trunks.

Why wrong: The native VLAN in 802.1Q trunks carries untagged frames; changing VLAN 70 to native would affect trunk tagging and could cause broadcast or misdelivery issues. However, the symptom is specifically that clients reach services by IP but not by hostname, indicating a DNS problem, not a Layer 2 forwarding issue. If the native VLAN were misconfigured, general connectivity would fail, not just name resolution.

The static route for 10.10.20.0/24 is missing from the routing table.

Why wrong: The routing table entry for 10.10.20.0/24 is visible in the output, showing 'via 10.10.10.2', so the static route is certainly not missing. This option misreads the table; the missing entry is actually the default route (0.0.0.0/0), not the static route to the 10.10.20.0 network. The presence of this specific static route does not affect the default route's reachability, which is the real issue.

The GigabitEthernet0/0 interface is administratively down.

Why wrong: The interface status in the exhibit is 'up/up' with IP address 10.10.10.1, and the connected route for 10.10.10.0/24 is present in the routing table. An administratively down interface would be 'shutdown' and would remove all connected routes, including the subnet that contains the next-hop. Since the next-hop is unreachable despite the interface being up, the problem lies with the remote router or Layer 2 connectivity, not the local interface state.

The default route is not configured; the gateway of last resort is missing.

Why wrong: The output includes the line 'Gateway of last resort is 10.10.10.2 to network 0.0.0.0', proving that a default route is configured and the router recognizes it as the gateway of last resort. However, the default route does not appear as an 'S*' entry in the routing table because the next-hop is unreachable. This option incorrectly assumes that the configuration is missing; in reality, the route is configured but not installed.

interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 10 interface GigabitEthernet0/2 switchport mode trunk switchport trunk allowed vlan 20 end show interfaces trunk

Why wrong: This is incorrect because trunk ports are used to carry multiple VLANs between switches, not to connect end devices like PCs and servers. Access ports should be used instead.

vlan 10 name PC_VLAN vlan 20 name Server_VLAN interface GigabitEthernet0/1 switchport mode access switchport access vlan 10 interface GigabitEthernet0/2 switchport mode access switchport access vlan 20 end show vlan brief

Why wrong: This is incorrect because it includes unnecessary VLAN creation and naming steps. While not harmful, the question only asks to assign ports to VLANs, not to create or name them. However, the main issue is that the configuration is valid but not minimal; the question expects only the required commands.

interface GigabitEthernet0/1 switchport access vlan 10 interface GigabitEthernet0/2 switchport access vlan 20 end show vlan brief

Why wrong: This is incorrect because it omits the 'switchport mode access' command. Without setting the port mode to access, the port may default to dynamic desirable or trunk mode, which could cause issues with VLAN assignment.

Increase the bridge priority on SW2 for VLAN 40.

Why wrong: Increasing the bridge priority on SW2 for VLAN 40 would assign a higher numeric priority value, making it less likely to become the root bridge for that VLAN. However, the root bridge election only determines the spanning-tree topology; it does not alter the fixed forward-delay timers of PVST+ that cause the 30-second reconvergence. Even if SW2 were the root, PVST+ still requires listening and learning delays, whereas Rapid PVST+ eliminates that delay via Proposal/Agreement. The correct fix is to switch the entire stack to Rapid PVST+, not to manipulate root priority.

Disable PortFast on all access ports.

Why wrong: Disabling PortFast on all access ports would force every host-facing port to spend 30 seconds in listening and learning states after any link event, making client connectivity worse. PortFast is designed only for edge ports and has no effect on the convergence of an inter-switch trunk when an uplink flaps. The 30-second outage on VLAN 40 stems from the root port transition on SW2's trunk, not from access port behavior, so this change would be counterproductive.

Convert the uplink to a routed port.

Why wrong: Converting the uplink to a routed port would eliminate Layer 2 spanning tree on that segment, but it would also terminate the VLAN 40 broadcast domain and require IP addressing on the links. This fundamentally changes the network design and does not address the STP reconvergence delay that occurs when the Layer 2 uplink flaps. The exhibit clearly indicates an STP mode mismatch, not a need for Layer 3 switching, so this is not a valid corrective action.

The trunk must be converted to an access port for VLAN 20 to work.

Why wrong: An access port is designed to carry a single untagged VLAN, so converting the trunk to an access port would force it to carry only the VLAN assigned as the access VLAN, such as VLAN 20. This would drop the tags for VLANs 10 and 30, making them unreachable across the link, which defeats the purpose of a trunk that must carry all three VLANs. Furthermore, trunk ports are the standard mechanism for inter-switch multi-VLAN traffic, and a misconfigured allowed list is a filtering problem, not a port-mode problem.

VLAN 20 must always be the native VLAN.

Why wrong: The native VLAN on an 802.1Q trunk is the VLAN that is transmitted without an 802.1Q tag; it is an untagged path used for control traffic and for devices that do not support VLAN tagging. VLAN 20 can be carried either as a tagged VLAN or as the native VLAN, but setting it as native would simply change the tagging behavior, not the allowed list. If VLAN 20 is missing from the allowed list, even untagged frames for the native VLAN will not be forwarded. Thus, native VLAN assignment is independent from the VLAN membership filtering issue.

The switches must both use ISL instead of 802.1Q.

Why wrong: ISL and 802.1Q are different trunking encapsulations; both use their own tagging format and both are capable of carrying VLAN 20 across a trunk. The problem described is that VLAN 20 is not in the allowed list on one side, which is a VLAN filter applied at the interface level regardless of the encapsulation protocol. Even if both switches were configured for ISL, the missing VLAN would still be omitted from the allowed list, so the traffic would still be blocked. Additionally, most Cisco switches today default to 802.1Q, and mixing encapsulations would break the trunk entirely.

All tagged VLAN traffic is automatically converted to routed traffic

Why wrong: A native VLAN mismatch does not alter the fundamental operation of a trunk link, which remains a Layer 2 forwarding path. The 802.1Q tag is still applied to frames from all non-native VLANs, and those frames are switched based on MAC addresses exactly as they would be with a correctly configured trunk. There is no mechanism that converts tagged VLAN traffic into routed traffic; routing would only occur if the frames are sent to a Layer 3 interface, which is a separate configuration unrelated to trunk native VLAN settings.

The mismatch forces OSPF adjacency reset on all routers

Why wrong: A native VLAN mismatch is a Layer 2 trunking misconfiguration; it directly affects only how untagged frames are interpreted on the trunk. OSPF adjacency is a Layer 3 routing process that relies on IP reachability and multicast hello packets, not on the native VLAN assignment of a trunk. While an IP connectivity issue could indirectly cause OSPF neighbors to go down, the mismatch itself does not force an OSPF adjacency reset on any router, and OSPF has no mechanism that reacts specifically to trunk native VLAN mismatches.

The trunk can carry only one VLAN until the mismatch is cleared

Why wrong: An 802.1Q trunk is designed to carry multiple VLANs simultaneously by adding a 4-byte tag to frames from all VLANs except the native VLAN. When a native VLAN mismatch exists, the untagged frames on the native VLAN are mishandled, but frames from other VLANs remain correctly tagged and continue to traverse the trunk normally. Therefore the trunk does not become limited to a single VLAN; it continues to transport all configured tagged VLANs, and only the untagged native VLAN traffic is subject to misassociation.

Replace the faulty Ethernet cable between the switch and the workstation.

Why wrong: Replacing the Ethernet cable is unlikely to resolve the issue because physical-layer faults such as a damaged cable typically produce observable error counters on the interface—for example, CRC errors, runts, giants, or interface resets. The described output does not report any of these increments, and the interface remains up/up; instead, the symptoms align with a logical Layer 1/2 configuration problem. A duplex mismatch does not generate CRC errors but causes late collisions and excessive deferrals, which are not corrected by swapping the cable.

Assign the switch port to the correct VLAN.

Why wrong: Assigning the switch port to the correct VLAN is not a valid fix because VLAN misconfiguration typically produces a total loss of connectivity rather than a gradual performance degradation—the workstation would fail to reach its default gateway or other subnets, and DHCP would likely fail. The interface in question is up/up and passing traffic, which indicates the port is already in an operational VLAN and layer 2 forwarding is working. Without evidence of unreachable peers or a VLAN membership mismatch in the output, this option does not address the observed symptom.

Disable spanning-tree on the port to prevent frequent topology changes.

Why wrong: Disabling spanning-tree on the port is incorrect because Spanning Tree Protocol (STP) itself does not cause slow throughput when the port is stable in the forwarding state. STP issues manifest as port flapping, listening/learning transitions, or err-disabled states, none of which appear in a show interface output that reports up/up. Frequent topology changes would be reflected in incrementing Topology Change Notification (TCN) counters, not in a persistent slow performance, so disabling STP would be both unnecessary and potentially harmful by enabling forwarding loops.

Because allowing a VLAN on a trunk automatically disables it

Why wrong: The command 'switchport trunk allowed vlan add 99' merely adds VLAN 99 to the list of VLANs whose tagged frames may traverse the trunk. This does not disable the VLAN; in fact, it explicitly permits it. A VLAN is disabled by using the 'no vlan 99' to remove it or 'shutdown vlan 99' to administratively bring it down. Thus, allowing a VLAN on a trunk never automatically disables it; the two operations are completely independent.

Because VLANs can cross trunks only when PAT is enabled

Why wrong: PAT (Port Address Translation) is a Network Address Translation technique that maps multiple private IP addresses to a single public IP address for outbound Internet traffic. Trunk operation is a Layer 2 function where 802.1Q tags in Ethernet frames identify different VLANs as they traverse a trunk link. PAT has no relationship to Layer 2 VLAN tagging or carriage across a trunk. VLANs cross trunks purely via 802.1Q or ISL encapsulation, not through PAT or any other Layer 3 translation mechanism.

Because VLAN 99 must always be the native VLAN

Why wrong: The native VLAN is a special VLAN on an 802.1Q trunk that carries its frames untagged, typically configured with 'switchport trunk native vlan <vlan-id>'. There is no requirement that VLAN 99 be the native VLAN; any VLAN can be configured as native, and any VLAN can be carried across a trunk as a tagged VLAN. If VLAN 99 is not the native VLAN, it simply sends and receives 802.1Q-tagged frames. Therefore, needing VLAN 99 to be the native VLAN is a misconception; its operability depends on it being defined and active, not on its native status.

OSPF authentication

Why wrong: OSPF authentication is a Layer 3 routing protocol feature that validates neighbor relationships by encrypting or hashing OSPF packets between routers. It does not inspect or control traffic from end hosts on a switchport, nor does it regulate MAC addresses. Since OSPF is concerned with route exchange in the control plane, it cannot enforce any policy on the data plane of an access port.

NetFlow

Why wrong: NetFlow is a traffic monitoring technology that samples and exports metadata about IP flows, such as source and destination addresses, ports, and byte counts. It provides visibility into traffic patterns but lacks any enforcement capability to block or limit which MAC addresses can use an access port. Therefore, while NetFlow could observe activity on a VLAN 10 port, it cannot directly control endpoint access or enforce security limits.

NTP

Why wrong: NTP is a protocol designed to synchronize clocks across network devices, ensuring consistent timestamps for logging and authentication. It has no mechanism to filter, block, or limit endpoints on a Layer 2 access port. Even if NTP were enabled on the switch, it would not prevent a host in VLAN 10 from sending traffic, making it wholly unrelated to port-level access control.

All ports in both VLANs configured as trunks

Why wrong: Configuring all ports in both VLANs as trunk ports is a Layer 2 operation that allows multiple VLANs to traverse a single link using 802.1Q tagging, which is designed for links between switches or between a switch and a router, not for connecting end hosts. Trunking does not perform any Layer 3 routing; it simply preserves VLAN tags so that traffic remains isolated at Layer 2. Even if every port is a trunk, the switch still lacks the Layer 3 interfaces and routing table entries necessary to forward packets between VLAN 10 and the other VLAN, so no inter-VLAN routing would occur.

A separate OSPF process on every access port

Why wrong: OSPF is a dynamic routing protocol that operates at Layer 3 to exchange route information between routers or multilayer switches, not between individual access ports. Access ports are Layer 2 interfaces that carry untagged traffic for a single VLAN and cannot run OSPF because they lack an IP address and are not routed interfaces. Even if you could enable OSPF, it would not create a routing path between VLANs; you would still need SVIs with IP addresses and a routing table. For simple inter-VLAN routing, OSPF is unnecessary and adds complexity without providing any benefit.

Port security disabled on every edge port

Why wrong: Port security is a Layer 2 security feature that restricts the MAC addresses allowed on a port to prevent unauthorized devices or MAC flooding attacks; it has absolutely no effect on the switch's ability to route at Layer 3. Disabling port security on edge ports only affects MAC address table learning and security policy enforcement, not the presence of SVIs or the IP routing configuration. Inter-VLAN routing is determined by whether the switch has routed interfaces for each VLAN and has IP routing enabled, so disabling port security cannot enable or disable routing between VLAN 10 and the other VLAN.

The native VLAN must be set to 30

Why wrong: The native VLAN is used exclusively for untagged frames on an 802.1Q trunk and defaults to VLAN 1; user data VLAN traffic is normally tagged, so setting the native VLAN to 30 would not affect traffic delivery for VLAN 30. Since the problem is that VLAN 30 frames are not permitted or are pruned on the trunk, adjusting the native VLAN would neither allow those frames onto the trunk nor resolve the allowed-list mismatch.

STP blocks all VLANs on the trunk when one VLAN fails

Why wrong: Spanning Tree Protocol operates on a per-VLAN basis (PVST/PVST+) or per-instance in MST, so STP independently evaluates blocking or forwarding state for each VLAN on the trunk. A failure such as VLAN 30 not being allowed on one side is an administrative filtering issue, not a Layer 2 loop condition, and STP would not respond by blocking all VLANs on the trunk merely because one VLAN's frames are not being transmitted.

The trunk must be changed to access mode for VLAN 30

Why wrong: Configuring the trunk as an access port would force the link to carry traffic for only a single, untagged VLAN, eliminating the multi-VLAN 802.1Q trunk entirely. This would break connectivity not only for VLAN 30 but also for VLAN 10 and any other VLANs currently traversing the link, so it is not a valid fix for the reported issue and would degrade the network further.

1. Enable DHCP relay on the VLAN 20 interface. 2. Configure the DHCP pool for VLAN 10. 3. Exclude addresses from the pool. 4. Verify DHCP operations.

Why wrong: This is incorrect because DHCP relay should be configured after the DHCP server pool is set up. Enabling relay before the server is ready may cause clients to send requests that cannot be answered.

1. Exclude addresses from the pool. 2. Enable DHCP relay on the VLAN 20 interface. 3. Configure the DHCP pool for VLAN 10. 4. Verify DHCP operations.

Why wrong: This is incorrect because the DHCP pool must be created before excluding addresses. Exclusions are part of the pool configuration and cannot be applied before the pool exists.

1. Configure the DHCP pool for VLAN 10. 2. Enable DHCP relay on the VLAN 20 interface. 3. Exclude addresses from the pool. 4. Verify DHCP operations.

Why wrong: This is incorrect because exclusions should be configured before enabling relay. Although the pool is created first, exclusions are part of the pool configuration and should be done before moving to relay.

Whether the switch should disable IP routing

Why wrong: Disabling IP routing on the switch would completely break the path between VLAN 10 and VLAN 20, because the switch's SVI would no longer forward packets between those subnets. The fact that the host can already ping its local SVI indicates that the switch's layer 3 interface is up and addressed correctly; the problem lies beyond the local subnet. To route between VLANs, IP routing must remain enabled—either on the switch (inter-VLAN routing) or on an external router—so disabling it is not a viable fix and would only worsen the situation.

Whether VLAN 10 should be the native VLAN

Why wrong: VLAN 10 being the native VLAN is irrelevant to this symptom. Native VLAN configuration only affects how frames are tagged on 802.1Q trunk links; frames on the native VLAN are sent untagged. The host's ability to ping its local SVI and then fail to reach a server in another VLAN points to layer 3 forwarding issues, not to the layer 2 trunk encapsulation or native VLAN mismatch. Checking native VLAN settings would be appropriate only if there were complete L2 connectivity failures, not selective inter-VLAN reachability.

Whether the host should use a /8 mask instead of /24

Why wrong: Changing the host's subnet mask from /24 to /8 would make the host assume the entire 10.0.0.0/8 address space is directly connected on its own VLAN. It would then attempt to ARP for the server's IP address instead of sending the packet to its default gateway, breaking communication even more. The given symptom—host can ping the local SVI—shows the host is already using a proper /24 mask and routing locally through its gateway; a /8 mask would create a completely different ARP-based failure, not resolve the current one.