Network Implementation practice questions

The trunk port is in an err-disabled state.

Why it fails: The trunk status is up/up, so it is not err-disabled. An err-disabled port would show as down.

The switchport mode is not set to trunk on one side.

Why it fails: If the trunk link is up/up, both sides are likely configured as trunk ports. The question states the trunk is configured, so this is not the issue.

The spanning-tree protocol is blocking VLAN 10 on the trunk.

Why it fails: Spanning tree can block specific VLANs if there is a loop, but for a simple two-switch topology this is unlikely. Moreover, the symptom is that hosts on the same VLAN cannot communicate, which is more indicative of a native VLAN issue.

The VLAN memberships on the access ports are correct.

Why it fails: VLAN Trunking Protocol (VTP) is an optional Cisco proprietary protocol used to propagate VLAN configuration changes across a network of switches within the same VTP domain. While VTP simplifies VLAN management, it is not a functional requirement for a trunk link to operate and carry traffic for configured VLANs. A mismatch in VTP domain names would prevent VLAN database synchronization but would not inherently stop traffic for existing, locally configured VLANs from traversing an otherwise operational trunk port.

The speed and duplex settings are identical.

Why it fails: Speed and duplex settings must be identical on interconnected switch ports to ensure proper communication and avoid performance issues. A mismatch, such as one port operating at full-duplex and the other at half-duplex, would lead to severe packet loss, excessive collisions, and a significant reduction in throughput across the entire link. However, these problems would affect all traffic indiscriminately, not selectively block only specific VLANs while others continue to pass.

The spanning tree protocol is disabled.

Why it fails: Disabling Spanning Tree Protocol (STP) on network switches removes the crucial mechanism designed to prevent Layer 2 loops. Without STP, redundant paths can create broadcast storms, MAC address table corruption, and network instability, potentially bringing down the entire network segment. While disabling STP is catastrophic, its impact is network-wide and does not selectively prevent traffic for certain VLANs from traversing a trunk while allowing others.

A: The switchport mode for VLAN 20 is set to access

Why it fails: Switchport modes are configured on the physical interface itself, not on a per-VLAN basis. If the uplink port connecting the switch to the router were configured in `access` mode, it would only carry traffic for a single, untagged VLAN. This configuration would entirely disable the trunking capability, preventing *any* tagged VLAN traffic, including both VLAN 10 and VLAN 20, from reaching the router, not just VLAN 20.

C: The router needs to be rebooted to apply the subinterface configuration

Why it fails: Router configurations, particularly for logical interfaces like subinterfaces, are applied dynamically and take effect immediately upon being entered and saved into the running configuration. Network devices are designed for continuous operation, and a reboot is not typically required for interface or routing protocol changes to become active. A reboot would only be necessary in rare circumstances, such as a major firmware upgrade or to clear a persistent software issue, which is not the case for a simple subinterface configuration.

D: The native VLAN on the trunk is misconfigured

Why it fails: The native VLAN on a trunk port is designated to carry untagged traffic across the link. While a native VLAN mismatch between a switch and a router's trunk port can cause issues like dropping untagged frames or security vulnerabilities, it would not specifically prevent *tagged* VLAN 20 traffic from reaching the router. Both VLAN 10 and VLAN 20 traffic are typically 802.1Q tagged, making the native VLAN configuration irrelevant to their communication unless one of them was erroneously configured as the native VLAN itself.

The native VLAN is different on each switch

Why it fails: A native VLAN mismatch between two switches on a trunk link primarily affects untagged traffic and can lead to control plane issues, such as problems with CDP or VTP advertisements. While it can cause connectivity problems for devices in the mismatched native VLAN and introduce security vulnerabilities, it does not typically prevent *all* tagged traffic for *other* VLANs from successfully traversing the trunk. Tagged frames for other VLANs would still be correctly encapsulated and forwarded.

VLAN 1 has been deleted on one of the switches

Why it fails: VLAN 1 is typically the default native VLAN and cannot be deleted on most enterprise-grade switches, such as Cisco devices, as it serves essential control plane functions. Even if it were possible to remove VLAN 1 on a specific platform, this action would not inherently prevent all traffic for *other* configured VLANs from traversing a properly established trunk link. The issue would primarily affect traffic explicitly assigned to VLAN 1, not the entire trunk's functionality for all tagged frames.

Spanning Tree Protocol is blocking the trunk link

Why it fails: Spanning Tree Protocol (STP) blocks redundant links to prevent network loops, but if a trunk link is configured and the physical interface is up, STP would generally allow traffic unless a loop is detected. If STP were blocking the link, the interface would typically be in a blocking state, preventing *any* traffic, not just specific VLAN traffic, and the scenario implies the link is operational for trunking configuration attempts. Therefore, STP blocking is an unlikely primary cause for a complete trunk failure.

Set the native VLAN to 20 on both switches

Why it fails: The native VLAN on a trunk port is specifically designated to handle untagged Ethernet frames, assigning them to that particular VLAN upon reception. While setting the native VLAN to 20 would assign untagged traffic to VLAN 20, it does not enable the transmission of *tagged* VLAN 20 traffic, which is typically how VLANs communicate across trunks. Furthermore, a mismatch in native VLANs between connected switches can lead to control plane issues, such as CDP/LLDP miscommunication, and dropped untagged frames.

Configure the trunk port as an access port in VLAN 20

Why it fails: An access port is designed to connect end devices to a single VLAN, transmitting and receiving untagged frames for that specific VLAN. Configuring a trunk port, which is intended to carry multiple VLANs using 802.1Q tagging, as an access port in VLAN 20 would effectively disable its ability to transport traffic for any other VLANs. This misconfiguration would prevent inter-VLAN communication across the switches, isolating all other VLANs and breaking the network's segmentation strategy.

Enable VLAN pruning for all VLANs on the trunk

Why it fails: VLAN pruning is a feature designed to optimize network bandwidth by preventing broadcast, unknown unicast, and multicast traffic for specific VLANs from traversing trunk links where those VLANs have no active ports. Enabling pruning does not inherently allow a VLAN to be carried; rather, it restricts the propagation of traffic for already-allowed VLANs. If VLAN 20 is not explicitly allowed on the trunk, pruning will not facilitate its transmission and may even prevent its traffic from reaching necessary destinations if misconfigured.

Set the port to trunk mode.

Why it fails: While `switchport mode trunk` is essential for establishing a trunk link, its primary function is to enable trunking on the interface. By default, once an interface is in trunk mode, it permits all active VLANs to traverse it. This command alone does not provide any mechanism to filter or restrict specific VLANs, making it insufficient for the stated goal of allowing *only* certain VLANs.

Assign the default native VLAN to the trunk.

Why it fails: The `switchport trunk native vlan 1` command designates VLAN 1 as the native VLAN for the trunk interface. Traffic belonging to the native VLAN is sent untagged across the trunk, and any untagged traffic received on the trunk is associated with this VLAN. While important for handling untagged frames and ensuring interoperability, this command does not filter or restrict which *tagged* VLANs are allowed to traverse the trunk link.

Enable 802.1Q encapsulation on the link.

Why it fails: The `switchport trunk encapsulation dot1q` command specifies that the IEEE 802.1Q standard will be used for VLAN tagging on the trunk link. This is a necessary configuration step for modern Cisco trunks to define how VLAN information is carried within Ethernet frames. However, it solely dictates the tagging method and has no function in controlling which specific VLANs are permitted or denied across the trunk.

The trunk port speed and duplex

Why it fails: While it is absolutely critical for any Ethernet link, including a trunk, to have matching speed and duplex settings on both connected interfaces, this is a fundamental requirement for physical layer connectivity rather than a specific configuration challenge unique to 802.1Q trunking. Mismatched speed or duplex settings would prevent the link from establishing or cause severe performance degradation due to collisions or dropped frames, but it's not an issue *specific* to the logical operation of VLAN tagging.

The encapsulation type

Why it fails: For an 802.1Q trunk to function, both connected interfaces must be configured to use the 802.1Q encapsulation type. If one end is configured for 802.1Q and the other for a different trunking protocol (like Cisco's proprietary ISL, if supported), or if one end is not configured for trunking at all, the trunk will fail to establish. However, in modern networks, 802.1Q is the universally adopted standard, making misconfiguration of the *type* of encapsulation less common than issues with specific parameters like the native VLAN ID.

The allowed VLAN list

Why it fails: The list of allowed VLANs on an 802.1Q trunk port can indeed be configured differently on each switch. If a VLAN is allowed on one end but not the other, traffic for that specific VLAN will simply not traverse the trunk from the disallowed side, or it will be dropped upon arrival if not allowed on the receiving end. However, this mismatch does not prevent the trunk from functioning correctly for the VLANs that *are* mutually allowed on both sides, nor does it typically cause a complete failure of the trunk link itself.

Enable port mirroring on the switch to monitor voice traffic and adjust bandwidth.

Why it fails: Port mirroring is used for monitoring and troubleshooting, not for prioritization. It does not affect how traffic is queued or forwarded. This would not ensure voice packets are prioritized, so it is not a valid solution.

Configure LLDP-MED and enable DSCP trust on the switch ports connected to IP phones.

Why it fails: LLDP-MED helps with device discovery and VLAN assignment, and DSCP trust is important for Layer 3 QoS. However, the question specifies CoS prioritization, which operates at Layer 2. Trusting DSCP alone without configuring CoS mapping may not prioritize voice frames correctly if they are tagged with CoS. This is not the most direct solution.

Enable 802.1Q trunking and set the native VLAN to 100 for voice traffic.

Why it fails: Setting the native VLAN to 100 for voice traffic is a security risk and does not provide prioritization. Native VLAN traffic is untagged and typically used for management. This does not ensure voice packets are prioritized, so it fails to meet the requirement.

Spanning Tree Protocol (STP)

Why it fails: Spanning Tree Protocol (STP) is a Layer 2 protocol designed to prevent switching loops in redundant network topologies by intelligently blocking redundant paths. It ensures that only one active path exists between any two network devices, thereby avoiding broadcast storms, MAC address table instability, and multiple frame copies. STP's role is solely to manage redundant links for loop prevention, not to logically segment a switch into multiple broadcast domains.

VLAN Trunking Protocol (VTP)

Why it fails: VLAN Trunking Protocol (VTP) is a Cisco proprietary protocol designed to manage and synchronize VLAN configurations across multiple switches within a single VTP domain. Its primary function is to propagate VLAN changes, such as creation, deletion, or renaming, from a VTP server to client switches, ensuring consistent VLAN definitions across the network. However, VTP itself does not create or segment broadcast domains; it merely facilitates the administrative management of existing or newly defined VLANs.

Access Control List (ACL)

Why it fails: An Access Control List (ACL) is a set of rules configured on a router or Layer 3 switch to filter network traffic based on criteria such as source/destination IP addresses, port numbers, or protocols. While ACLs are crucial for network security and traffic management by permitting or denying specific packets, they operate at Layer 3 and above in the OSI model. They do not segment a network into separate broadcast domains, which is fundamentally a Layer 2 function.

Default route (0.0.0.0/0)

Why it fails: The default route, represented as 0.0.0.0/0, serves as a last resort for a router when no more specific route matches the destination IP address. It acts as a catch-all for traffic that doesn't fit any other known network. Since there are more precise routes available in the routing table that specifically match the 10.0.0.15 destination, such as 10.0.0.0/16, the default route will not be utilized for this packet.

10.0.0.0/8 via 192.168.1.1

Why it fails: While the destination IP address 10.0.0.15 certainly falls within the broad 10.0.0.0/8 network, this route is significantly less specific than the 10.0.0.0/16 route. Routers strictly adhere to the "longest prefix match" rule, meaning they always select the route with the most matching bits in the network address. Consequently, the /8 route is overlooked in favor of the more precise /16 entry.

None; the packet is dropped

Why it fails: A packet is only dropped if a router cannot find any matching route in its routing table for the destination IP address, including a default route. In this scenario, multiple routes, such as 10.0.0.0/16, 10.0.0.0/8, and the default route, are available that encompass the 10.0.0.15 destination. Therefore, the packet will be successfully forwarded, not dropped.

Electromagnetic interference

Why it fails: Fiber optic cables transmit data as pulses of light through a glass or plastic core, making them fundamentally immune to electromagnetic interference (EMI). Unlike copper cabling, which relies on electrical signals susceptible to external electromagnetic fields from power lines, motors, or radio frequencies, fiber optics are unaffected. Therefore, EMI cannot induce signal weakening or data corruption in a fiber optic connection, rendering it an irrelevant factor for this issue.

Incorrect termination

Why it fails: While incorrect termination can cause light loss, the most likely issue over such a long distance is distance-related attenuation. Termination issues are more likely to cause total failure or high loss at the connection points, not gradual weakening along the run.

Crosstalk

Why it fails: Crosstalk is a phenomenon primarily associated with copper cabling, where electromagnetic coupling between adjacent wire pairs causes unwanted signal interference from one circuit to another. Since fiber optic cables transmit data using light pulses within individual glass strands, there is no electromagnetic field generated that could induce interference into an adjacent fiber. Consequently, fiber optic connections are inherently immune to crosstalk, making it an impossible cause for signal weakening in this scenario.

The printer is on a different VLAN

Why it fails: In a small office with a simple wireless router, VLANs are rarely configured. Even if VLANs were used, the router would need to route between them, and the printer's IP 192.168.1.50 suggests the same VLAN as the laptop (192.168.1.100).

The default gateway is misconfigured

Why it fails: A misconfigured default gateway on the printer would not prevent communication with the laptop if both devices are intended to be on the same local subnet. Devices communicate directly within their local subnet using Address Resolution Protocol (ARP) to map IP addresses to MAC addresses, bypassing the gateway. The default gateway is only utilized when a device needs to send traffic to an IP address located on a different subnet, so its misconfiguration would not impact local peer-to-peer communication.

The DHCP scope is exhausted

Why it fails: The laptop obtained an IP (192.168.1.100), so the DHCP scope is not exhausted. DHCP scope exhaustion would prevent new devices from getting IP addresses, but the printer has a static IP, so it is not affected by DHCP.

Mismatched encryption algorithms between the two VPN peers

Why it fails: If encryption algorithms were mismatched, the tunnel would not establish. Since the tunnel is up, this is not the issue.

Firewall on the main office server blocking ICMP

Why it fails: While possible, the main office can ping the branch gateway, and if the tunnel is up, firewall rules affecting ICMP are less likely the root cause compared to missing routing.

Incorrect IKE authentication settings

Why it fails: IKE authentication issues would prevent the tunnel from being established; since the tunnel is active, this is not the cause.

VLAN 20 is not allowed on the trunk to the router

Why it fails: If VLAN 20 is explicitly disallowed on the trunk link connecting the switch to the router, it would indeed prevent devices in VLAN 20 from communicating with devices in *other* VLANs or external networks. This is because inter-VLAN routing relies on the router receiving tagged frames for all allowed VLANs. However, this specific configuration issue would not impact communication *between* devices that are all members of VLAN 20 and connected to the same switch or switches where VLAN 20 is properly configured, as intra-VLAN communication does not traverse a router.

The server does not have a default gateway configured

Why it fails: A default gateway is a crucial IP address that enables a device to send traffic to destinations outside its immediate local IP subnet, typically to other VLANs or the internet. However, communication between devices residing within the *same* VLAN and IP subnet occurs at Layer 2 and does not require a default gateway. Therefore, the absence of a default gateway would not prevent the new server from communicating with other devices that are also members of VLAN 20.

The port is administratively down

Why it fails: If a switch port is administratively down, it signifies that the port has been manually disabled by a network administrator using a command like "shutdown." In such a state, the port would not establish a link or pass any traffic whatsoever, resulting in a complete lack of physical layer connectivity for the server. The question implies the server is connected but merely unable to communicate within VLAN 20, which suggests the port is physically up but logically misconfigured, not entirely disabled.

B) Native VLAN mismatch on the trunk

Why it fails: A native VLAN mismatch primarily affects untagged frames traversing a trunk link, causing them to be misdirected or dropped as they are assigned to different native VLANs on each side. However, traffic for VLAN 10, when sent over an 802.1Q trunk, is typically explicitly tagged with the VLAN 10 identifier. Therefore, a native VLAN mismatch would not specifically prevent the forwarding of properly tagged VLAN 10 frames, assuming VLAN 10 is allowed on the trunk and exists on both switches.

C) Trunk encapsulation mismatch (ISL vs 802.1Q)

Why it fails: A trunk encapsulation mismatch, such as one switch configured for 802.1Q and the other for ISL, would prevent the two switches from correctly interpreting each other's trunking frames. This fundamental disagreement in frame formatting would typically cause the trunk link to fail to establish, continuously flap, or experience severe errors, making it impossible for any VLAN traffic, including VLAN 10, to pass reliably. The question implies the trunk is operational, making this an unlikely cause.

D) STP is blocking the VLAN 10 traffic on the trunk

Why it fails: Spanning Tree Protocol (STP) is designed to prevent network loops by blocking redundant paths, ensuring a loop-free logical topology. On a single, non-redundant trunk link between two switches, STP would typically place the port in a forwarding state for all allowed VLANs, including VLAN 10, unless a loop is detected elsewhere in the topology. If the trunk is 'up/up,' it indicates the port is forwarding, meaning STP is not blocking traffic on this specific link.

B) Different channels per AP to reduce interference

Why it fails: While deploying different, non-overlapping channels for adjacent Access Points (APs) is a fundamental best practice to minimize co-channel interference and maximize overall network throughput, this configuration primarily optimizes performance. Channel selection does not directly govern a client device's ability to roam. Roaming is instead driven by the client identifying the same logical network (SSID) and having valid security credentials, regardless of the specific radio channel an AP is currently utilizing.

C) WPA2-Enterprise with RADIUS authentication

Why it fails: WPA2-Enterprise, coupled with RADIUS authentication, provides robust, centralized security and granular user access control, which is highly beneficial for corporate environments requiring strong authentication. However, implementing WPA2-Enterprise is not a prerequisite for successful client roaming. Roaming functionality fundamentally relies on the client's ability to quickly re-associate with another Access Point broadcasting the same SSID and security parameters, whether those are a pre-shared key (WPA2-Personal) or enterprise-level credentials.

D) Mesh topology for AP interconnection

Why it fails: A mesh topology describes the wireless interconnection of Access Points (APs) to each other and to the wired network, often used to extend coverage without running Ethernet cables to every AP. This method of backhaul, while convenient for infrastructure deployment, does not directly influence how client devices roam between APs. Client roaming is a function of the client's ability to detect and transition between APs broadcasting the same SSID and security settings, independent of the APs' internal network connectivity method.

Site-to-site IPsec VPN with static IPs

Why it fails: A traditional site-to-site IPsec VPN typically requires static public IP addresses for both the hub and each spoke. This is because the IPsec Security Associations (SAs) are usually configured with specific peer IP addresses, which are are used for authentication and tunnel establishment. If a branch office's IP address changes dynamically, the pre-configured IPsec tunnel parameters become invalid, breaking connectivity and requiring manual reconfiguration or reliance on more advanced dynamic IPsec features.

Remote access VPN using SSL

Why it fails: Remote access VPNs, often utilizing SSL/TLS, are designed for individual users or client devices to securely connect to a corporate network from remote locations. This solution establishes a secure tunnel between a single client and a VPN concentrator, allowing the client to access internal resources. It is not intended for connecting entire branch office networks (LAN-to-LAN) to a central site, as it lacks the necessary routing and network-level encapsulation for site-to-site connectivity.

Policy-based VPN

Why it fails: Policy-based VPNs rely on access control lists (ACLs) or traffic selectors to define which specific traffic flows are encrypted and sent over the VPN tunnel. These policies are typically configured with explicit source and destination IP addresses or subnets. While robust for specific traffic, they do not inherently provide a mechanism for dynamically updating tunnel endpoints or traffic selectors when branch office IP addresses change, making them unsuitable for dynamic IP environments without additional complex configurations.

802.11n

Why it fails: While 802.11n introduced significant improvements like MIMO and dual-band operation (2.4 GHz and 5 GHz), its maximum theoretical throughput of up to 600 Mbps is considerably lower than newer standards. Although it was a high-performance standard in its time, it cannot meet the demands of modern 'high throughput' requirements as effectively as 802.11ac.

802.11g

Why it fails: 802.11g operates solely in the crowded 2.4 GHz band, which is prone to interference from other devices like microwaves and Bluetooth. Its maximum theoretical throughput is limited to 54 Mbps, which is insufficient for supporting contemporary high-bandwidth applications or a network requiring substantial data transfer capabilities.

802.11b

Why it fails: 802.11b is an older standard that operates exclusively in the highly congested 2.4 GHz frequency band. With a maximum theoretical throughput of only 11 Mbps, it is completely inadequate for any modern network requiring high data transfer speeds or supporting multiple users simultaneously. This standard is considered obsolete for performance-oriented deployments.

A) 802.11b

Why it fails: 802.11b operates exclusively within the highly congested 2.4 GHz frequency band, limiting its utility for a network requiring dual-band support. With a maximum theoretical throughput of only 11 Mbps, it is significantly slower than newer standards and is considered obsolete for modern deployments. Therefore, it cannot meet the requirement to support both 2.4 GHz and 5 GHz.

B) 802.11g

Why it fails: 802.11g exclusively utilizes the 2.4 GHz frequency band, offering a maximum theoretical throughput of 54 Mbps, which was a significant improvement over 802.11b. Although it provides backward compatibility with 802.11b devices, its inability to operate in the 5 GHz band makes it unsuitable for a network needing to support both 2.4 GHz and 5 GHz simultaneously. This single-band limitation directly contradicts the question's requirement.

D) 802.11ac

Why it fails: 802.11ac is designed to operate solely within the 5 GHz frequency band, leveraging wider channels and more spatial streams for very high throughput. While it offers superior speed and less interference in the 5 GHz spectrum, its exclusive operation in this band means it inherently lacks support for 2.4 GHz devices. Consequently, it fails to meet the fundamental requirement of supporting both frequency bands.

A) That the DNS server addresses are correctly configured

Why it fails: Domain Name System (DNS) servers translate human-readable domain names into IP addresses, which is essential for accessing resources by name. While correct DNS configuration is vital for users to resolve internal or external hostnames, it does not directly impact the ability of an IPSec site-to-site VPN tunnel to establish or forward IP packets between two specific IP subnets. The problem described, where the tunnel is "up" but no traffic passes, points to a Layer 3 routing issue, not a name resolution failure.

C) That the MTU size is set to 1500 on both ends

Why it fails: The Maximum Transmission Unit (MTU) defines the largest packet size, in bytes, that a network interface can send without fragmentation. While an MTU mismatch or an MTU that is too large for the encapsulated VPN traffic can lead to fragmentation, reassembly issues, or even packet drops (often referred to as "black holing"), it typically manifests as intermittent connectivity or slow performance rather than a complete lack of traffic when the tunnel is established. The core problem of "no traffic passes" when the tunnel is up usually indicates a fundamental routing misconfiguration preventing packets from even entering the tunnel.

D) That the SSID is correctly configured on the access points

Why it fails: The Service Set Identifier (SSID) is a name that identifies a wireless local area network (WLAN) and is broadcast by access points for client devices to connect. While crucial for wireless client connectivity, the SSID configuration on access points is entirely irrelevant to the establishment or traffic forwarding of a site-to-site IPSec VPN tunnel between two routers. VPN tunnels operate at Layer 3 (Network Layer) and above, typically over wired connections or existing internet infrastructure, independent of wireless network identifiers.