VLAN and Inter-VLAN Routing Scenarios

STP

Why it fails: Spanning Tree Protocol (STP) is designed to prevent Layer 2 loops by managing redundant paths in the network. It does not possess any capabilities for VLAN database synchronization or management. STP focuses entirely on link state and topology stabilization, not on logical grouping or VLAN identifier propagation.

CDP

Why it fails: Cisco Discovery Protocol (CDP) is a proprietary Layer 2 protocol used to share information about connected Cisco devices, such as hardware model and software version. It is a monitoring and discovery tool, not a management protocol, and does not synchronize or manage VLAN databases across the infrastructure.

OSPF

Why it fails: Open Shortest Path First (OSPF) is a dynamic interior gateway routing protocol used to calculate the best path in an IP network. It has no function related to Layer 2 VLAN configuration or database synchronization; its primary domain is routing table population and network reachability maintenance.

Reconfigure the default gateway on all hosts in VLAN 20 to point to the VLAN 40 SVI address.

Why it fails: Hosts should point to the gateway address of their own VLAN, not to another VLAN's interface. Changing VLAN 20 clients to use the VLAN 40 SVI would break their existing connectivity to VLAN 30 as well. This misconfiguration would widen the outage instead of fixing the VLAN 40 reachability problem.

Replace the Layer 3 switch with a router that has physical interfaces for each VLAN.

Why it fails: Replacing hardware is a drastic action that ignores diagnosis. The existing Layer 3 switch already routes between two working VLANs, so its routing capability is proven. The failure is isolated to one destination VLAN, which points to a configuration or status issue rather than a hardware limitation. This step would disrupt the working network without addressing the root cause.

Disable inter-VLAN routing and rely on Layer 2 flooding to deliver traffic between VLANs.

Why it fails: Layer 2 flooding cannot cross VLAN boundaries because each VLAN is a separate broadcast domain. Disabling routing would eliminate the working connectivity between VLAN 20 and VLAN 30 and would not make VLAN 40 reachable. This action misunderstands how inter-VLAN communication actually occurs, which always requires a Layer 3 function.

Implementing a standard Access Control List.

Why it fails: Standard ACLs filter traffic based on source IP address alone. They cannot inspect or strip 802.1Q tags, nor can they prevent the underlying mechanism of double-tagging from occurring. Therefore, they are ineffective against layer 2 VLAN hopping attacks, which operate below the IP layer where standard ACLs are applied.

Configuring PortFast on all access ports.

Why it fails: PortFast is designed to expedite the transition of a port to the forwarding state by bypassing the Spanning Tree Protocol listening and learning states. It provides no security benefit regarding VLAN hopping or frame tagging and, if misconfigured, can potentially lead to bridging loops in the network environment.

Enabling VTP pruning on the switch.

Why it fails: VTP pruning is used to optimize network bandwidth by restricting unnecessary traffic to switches that do not have active ports in specific VLANs. While it improves efficiency, it does not provide any security features to prevent frame manipulation or tag-based attacks, such as double-tagging or switch spoofing.

Native VLAN

Why it fails: The native VLAN is used on 802.1Q trunk ports to carry untagged traffic. It is not inherently a management VLAN, although it can be configured as one. However, the scenario does not mention trunking or untagged traffic; it focuses on creating a separate VLAN for management. The native VLAN concept is unrelated to the specific goal of isolating management traffic in this context.

Data VLAN

Why it fails: A data VLAN is used to carry user-generated traffic, such as email, web browsing, and file transfers. It is not intended for management access to network devices. The scenario specifically requires isolation of management traffic, so a data VLAN would not fulfill the requirement. The engineer needs a VLAN dedicated to management functions, not user data.

Voice VLAN

Why it fails: A voice VLAN is designed to carry Voice over IP (VoIP) traffic, ensuring that voice packets receive priority and are separated from data traffic. It is not used for switch management. The scenario describes management traffic isolation, not voice traffic, so a voice VLAN is inappropriate. The engineer should not configure a voice VLAN for this purpose.

Port security with sticky MAC address learning

Why it fails: Port security restricts which source MAC addresses may appear on a switch port and can shut the port or drop frames when a violation occurs. It operates at Layer 2 and has no concept of permitted management IP subnets, so it cannot selectively allow management stations by IP address or log denied IP-based attempts.

Dynamic ARP Inspection on all user-facing ports

Why it fails: Dynamic ARP Inspection validates ARP packets against the DHCP snooping binding table to stop ARP cache poisoning. It inspects ARP message contents at Layer 2 and does not filter general IP traffic by source subnet, so it cannot restrict which stations reach the management VLAN, and it produces no IP-based deny logging.

BPDU Guard enabled on access ports

Why it fails: BPDU Guard err-disables a port if it receives bridge protocol data units, protecting the spanning tree topology from rogue switches. It has nothing to do with permitting management source addresses; enabling it would not restrict access to the management VLAN and could actually disrupt legitimate edge devices that send BPDUs.

Incorrect DNS server

Why it fails: While an incorrect DNS server prevents users from resolving hostnames to IP addresses, it does not stop a technician from reaching remote resources via direct IP pings. Since the technician cannot reach any resources outside the subnet, the issue lies deeper in the routing logic than simple name resolution services.

Duplicate IP address

Why it fails: A duplicate IP address usually causes intermittent connectivity or total failure for the specific host involved, often triggering an ARP error message on the operating system. It would typically affect local connectivity as much as remote connectivity, which does not match the symptoms of local success but remote failure.

Faulty Cat6 cabling

Why it fails: Faulty cabling would generally impact all network traffic, regardless of whether the destination is local or remote. If the technician can successfully ping local servers, the physical layer connectivity between the host and the switch is confirmed to be working, ruling out a basic hardware failure in the cable.

Increased physical cabling requirements

Why it fails: VLANs actually decrease the need for physical cabling by allowing users in different locations to belong to the same logical segment. Implementing VLANs simplifies the physical infrastructure, as logical grouping is handled by software configuration on the switches themselves.

Automatic encryption of all traffic

Why it fails: VLANs provide isolation but do not encrypt data. Traffic between VLANs is typically routed in clear text unless higher-layer security protocols like IPsec or TLS are implemented. Relying on VLANs for encryption is a common misconception that creates significant security vulnerabilities.

Elimination of the need for routers

Why it fails: VLANs do not eliminate the need for routers; in fact, they necessitate inter-VLAN routing for communication between segments. Because each VLAN is a distinct subnet, a Layer 3 device is required to facilitate traffic flow between them, making routers essential.

The switch has learned the MAC address but the port is blocked.

Why it fails: If the switch had learned the MAC address, it would be listed in the table regardless of whether Spanning Tree was blocking the port. The absence of the MAC address indicates that no frames have reached the switch's processing engine from that specific physical port since the table was last cleared.

Port Fa0/2 is configured as a trunk port and is filtering traffic.

Why it fails: Trunk ports still learn MAC addresses for all the VLANs they carry. If Fa0/2 were a trunk, you would likely see multiple MAC addresses from various VLANs associated with it. The total absence of the port in the table indicates a lack of any incoming traffic, not a specific VLAN filtering issue.

The host on Fa0/2 is using a static IP address.

Why it fails: The use of a static IP address does not prevent a switch from learning a MAC address. As long as the host sends any Ethernet frame (such as an ARP request or a gratuitous ARP), the switch will record the source MAC address. The MAC table tracks hardware addresses, which are independent of IP configuration.

The SVI administrative configuration contains a mismatched IP subnet mask compared to the connected default gateway.

Why it fails: A subnet mask mismatch affects routing and IP packet forwarding, but it does not cause the interface line protocol to transition to the down state. The line protocol reflects Layer 2 operational framing and physical readiness.

The global routing command has not been enabled on the multilayer switch using the ip routing configuration command.

Why it fails: Without ip routing the switch cannot route between VLANs, but the SVI still comes up when the VLAN exists and has an active access port; line protocol down instead indicates no active member ports or a VLAN mismatch. It is tempting because routing is needed for inter-VLAN traffic, yet that is a separate requirement from SVI protocol state.

The physical transceiver connected to GigabitEthernet0/1 has experienced a complete hardware optical laser failure.

Why it fails: A laser failure would drop the physical link, so line protocol on the physical port would go down and Vlan100 would show down/down, not up/down. It is tempting because optical transceiver faults do cause interface outages, but they manifest as a down physical interface rather than a VLAN SVI with line protocol down.

The switch needs the ip routing global configuration command enabled so that it can forward frames between VLAN 10 and VLAN 20.

Why it fails: The ip routing command enables Layer 3 routing functionality on a multilayer switch that supports it, but this branch switch is described as a Layer 2 access switch with no routing capability. Enabling that command on a Layer 2-only platform has no effect and would not create a path between VLANs. The real issue is the absence of any Layer 3 device, not a disabled feature on the access switch.

The access ports must be configured as trunk ports so that frames from both VLANs can be carried between them.

Why it fails: Trunk ports carry traffic for multiple VLANs between network devices such as switches, but they do not route traffic between VLANs. Configuring an access port as a trunk would not allow a host in VLAN 10 to reach a host in VLAN 20, because the frames still need a Layer 3 decision. The problem is the missing router or multilayer switch, not the port mode of the access ports.

Spanning Tree Protocol has blocked the redundant path between the two VLANs, preventing traffic from flowing between them.

Why it fails: Spanning Tree Protocol operates within a Layer 2 topology to prevent loops by blocking redundant links; it does not create or block paths between separate VLANs. VLAN 10 and VLAN 20 do not share a Layer 2 forwarding path at all, so STP state is irrelevant to their mutual reachability. The connectivity failure stems from the lack of Layer 3 routing, not from a blocked spanning-tree port.

vlan 1

Why it fails: This command creates or modifies a VLAN in the VLAN database, but it does not create a Layer 3 interface. The vlan command is used to define VLANs and assign names, not to configure an SVI for management access. To assign an IP address, an SVI must be created using interface vlan 1.

interface fastethernet 0/1

Why it fails: This enters configuration for a physical switch port, which is a Layer 2 interface. Physical switch ports do not accept IP addresses directly in Cisco IOS (unless configured as routed ports on multilayer switches). The management IP must be assigned to an SVI, not a physical interface. This command would not create a management interface.

ip address 192.168.1.10 255.255.255.0

Why it fails: This command assigns an IP address to an interface, but it must be executed from within interface configuration mode. It does not create the interface itself. The technician first needs to create the VLAN interface and then enter this command. Using it at the global configuration prompt would result in an error.

Layer 2 Switch

Why it fails: Layer 2 switches operate only at the Data Link layer and make forwarding decisions based on MAC addresses. They lack the logic to process Layer 3 headers or route traffic between different IP subnets, making them incapable of performing inter-VLAN routing in any network topology.

Hub

Why it fails: A hub is a legacy physical layer device that broadcasts all incoming data to every connected port. It has no intelligence to distinguish between subnets or VLANs and cannot perform any routing functions, as it does not operate at the Data Link or Network layers at all.

Repeater

Why it fails: A repeater is a simple device used to regenerate signals over long distances to prevent attenuation. It operates exclusively at the Physical layer and possesses no networking intelligence. It is completely unsuitable for routing or managing traffic between distinct VLANs within a structured enterprise network infrastructure.

Access port

Why it fails: An access port carries traffic for only one VLAN and is typically used for end devices like computers or printers. It cannot support multiple VLANs on a single physical interface, so it does not meet the requirement for the server to be reachable by multiple VLANs without an external router.

Spanning Tree Protocol

Why it fails: Spanning Tree Protocol prevents Layer 2 loops by blocking redundant paths. It does not provide multi-VLAN connectivity on a single port. While important for network stability, it does not fulfill the scenario's need for a server to be reachable by multiple VLANs without routing through an external router.

Port mirroring

Why it fails: Port mirroring copies traffic from one port to another for monitoring purposes. It does not enable multiple VLANs on a single port or provide connectivity between VLANs. Therefore, it is not suitable for making a server reachable by multiple VLANs without an external router.

The default VLAN uses a different encapsulation type (ISL) that fragments frames larger than 1500 bytes, increasing overhead.

Why it fails: Cisco switches use IEEE 802.1Q trunking by default on modern platforms, not ISL, and VLAN membership does not fragment frames. Frame fragmentation is not a function of VLAN assignment. The performance issue described is due to broadcast flooding within one VLAN, not encapsulation or fragmentation.

VLAN 1 is reserved for management traffic only, so user data is automatically redirected to a separate data VLAN, causing congestion.

Why it fails: VLAN 1 is not reserved exclusively for management; it is the default VLAN for all ports and can carry user data. No automatic redirection to a data VLAN occurs unless an administrator manually configures that. The slowdown in this scenario is caused by a single broadcast domain, not by management reservation.

Because VLAN 1 is the native VLAN, it cannot carry IPv4 traffic, and packets are dropped, forcing retransmissions that slow the network.

Why it fails: The native VLAN on a trunk is the VLAN that carries untagged traffic; it does not prevent IPv4 traffic on access ports. VLAN 1 can carry IPv4 frames normally. The symptom of simultaneous transmissions slowing the network is consistent with a single broadcast domain, not with dropped packets due to native VLAN restrictions.

show vlan brief

Why it fails: show vlan brief displays VLAN membership and port assignments on a switch. While it confirms that the user's port and the server's port are in the correct VLANs, it does not verify Layer 3 routing functionality or the presence of routes between VLANs. This command would not confirm whether inter-VLAN routing is operational.

show interfaces trunk

Why it fails: show interfaces trunk shows trunk ports and allowed VLANs. This is useful if the server were on a different switch connected via a trunk, but the scenario states the network uses a Layer 3 switch for inter-VLAN routing, implying local VLANs. Trunk status does not verify routing between SVIs on the same switch.

show mac address-table

Why it fails: show mac address-table displays MAC address to port mappings. While it can confirm that the server's MAC is learned on a port, it does not indicate whether Layer 3 routing is enabled or if routes exist between VLANs. The MAC table operates at Layer 2 and does not reflect IP routing configuration.