VLAN and Inter-VLAN Routing Scenarios

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Increase the bridge priority on SW2 for VLAN 40.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Whether the switch should disable IP routing

Why it fails: 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 it fails: 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 it fails: 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.

Configure a default gateway on PC-A with the IP address 192.168.10.1.

Why it fails: This is incorrect because PC-A has an APIPA address (169.254.23.45), which indicates it did not receive a DHCP lease. Manually setting a default gateway does not resolve the underlying issue of DHCP failure. The PC must first obtain a valid IP address via DHCP before a default gateway can be used.

Change the VLAN on SW1's interface connected to PC-A from VLAN 10 to VLAN 1.

Why it fails: This is incorrect because PC-A is configured for VLAN 10, and the DHCP pool is on subnet 192.168.10.0/24, which is associated with VLAN 10. Changing to VLAN 1 would place PC-A in a different subnet, preventing it from receiving a DHCP lease from R1's pool. The VLAN configuration is correct as is.

Add the 'ip helper-address' command on R1's interface connected to SW1.

Why it fails: This is incorrect because the DHCP server is on R1 itself, not on a remote server. The 'ip helper-address' command is used to forward DHCP broadcasts to a DHCP server on a different subnet. Since R1 is the DHCP server, no helper address is needed; the router will respond to DHCP requests on its directly connected interface.

interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 10,20 power inline auto ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 30 power inline never

Why it fails: This is incorrect because the IP phone port should be an access port, not a trunk. Using a trunk port would require the phone to negotiate trunking, which is not the standard Cisco IP phone deployment. The voice VLAN is configured via 'switchport voice vlan', not by trunking.

interface GigabitEthernet0/1 switchport mode access switchport access vlan 20 switchport voice vlan 10 power inline auto ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 30 power inline never

Why it fails: This is incorrect because the voice VLAN should be 20, not the access VLAN. The access VLAN is for data traffic (typically VLAN 10), and the voice VLAN is for voice traffic. Swapping them would put voice traffic in VLAN 10 and data in VLAN 20, which is not the requirement.

interface GigabitEthernet0/1 switchport mode access switchport access vlan 10 switchport voice vlan 20 power inline never ! interface GigabitEthernet0/2 switchport mode access switchport access vlan 30 power inline auto

Why it fails: This is incorrect because PoE is disabled on the IP phone port (G0/1) and enabled on the AP port (G0/2), which is the opposite of what is required. The IP phone needs PoE to power on, and the AP should have PoE disabled.