Diagnosing Problems practice questions

Replace the Ethernet cable.

Why it fails: If the physical layer were the issue, the interface status would typically show 'down/down'. Since the interface is 'up', the cable is providing a signal. Replacing it is unnecessary at this stage, as the problem lies within the layer 2 logical protocol negotiation rather than physical layer signal continuity.

Check the power supply of the switch.

Why it fails: Power supply issues would result in a complete failure of the switch or the interface card, causing a 'down/down' state. Since the hardware has enough power to establish a physical link, investigating the power supply is not the correct diagnostic step for a 'line protocol down' error message.

Restart the spanning-tree process.

Why it fails: Spanning-tree manages loops at layer 2 but does not usually prevent the line protocol from coming up unless the port is in a blocked state due to a loop. Even then, the line protocol should be up. Restarting spanning-tree is a risky step that may cause network-wide instability.

Router Priority

Why it fails: Router priority is used for the DR/BDR election process on multi-access segments. While it influences which router becomes the designated router, it does not prevent the initial formation of neighbor adjacencies. Adjacencies will still form regardless of the priority value, so it is not a cause of failure.

OSPF Process ID

Why it fails: The OSPF process ID is locally significant to the router and does not need to match between neighbors. Two routers can form an OSPF adjacency even if they are using different process IDs on their local configurations, so verifying this value is unnecessary when troubleshooting adjacency failures.

Excessive CRC errors on the port.

Why it fails: CRC errors are physical layer issues caused by electrical noise, faulty cables, or transceiver failures. A VLAN mismatch is a logical layer 2 configuration issue that does not affect the physical framing of the signal, so it will not cause CRC errors on the interface.

The trunk port enters err-disabled state.

Why it fails: A native VLAN mismatch does not trigger an err-disabled state. The port will remain up, but traffic will be forwarded incorrectly between VLANs. Other features like PortFast or BPDU guard are more likely to cause an err-disabled state, but a VLAN mismatch itself does not.

The switch fails to obtain an IP address.

Why it fails: While communication may be impacted if the management VLAN is involved, a native VLAN mismatch does not directly prevent a switch from obtaining an IP address through DHCP or static configuration. This is a configuration-specific issue that would affect traffic passing through the trunk, not the switch's identity.

BPDU Guard

Why it fails: BPDU Guard is a security feature that shuts down a port if it receives a BPDU. While it protects the network from unauthorized switches, it does not stop the port from triggering STP changes when the link state flaps; it only enforces the port type through error-disabling.

Root Guard

Why it fails: Root Guard is designed to prevent a port from becoming a root port by forcing it to be a designated port. It is a security mechanism for the STP topology and has nothing to do with preventing flapping interfaces from triggering STP changes when connected to a standard end-host device.

EtherChannel

Why it fails: EtherChannel is used to aggregate multiple physical ports into a single logical link for increased bandwidth and redundancy. It is not designed to suppress STP recalculations caused by link flaps on individual ports. In fact, EtherChannel itself requires careful configuration to avoid STP issues, making it unsuitable for this purpose.

show ip route

Why it fails: This command displays the Layer 3 routing table and is used to troubleshoot path selection and reachability between subnets. It does not provide any information about physical layer errors, signal quality, or hardware-level frame corruption. Routing issues are logical, whereas the technician is specifically looking for physical layer diagnostics.

show running-config

Why it fails: The running configuration shows how the interface is 'supposed' to behave based on administrator settings. While it can reveal a manual speed/duplex mismatch, it does not show the actual error counters or the operational status of the link. It tells you the 'intent', not the actual 'result' of the connection.

show vlan brief

Why it fails: This command lists the VLANs and the ports assigned to them. It is helpful for troubleshooting logical segmentation and broadcast domains but provides zero visibility into physical signal errors or frame corruption. VLAN membership is a logical assignment that exists independently of the physical health of the underlying cable.

Broadcast storm

Why it fails: Broadcast storms usually overwhelm the entire segment or VLAN, causing high CPU usage on all devices and flickering LEDs. While they slow down performance, they are not typically caused by a single host's auto-negotiation setting, making this an unlikely cause compared to a direct physical layer mismatch.

VLAN mismatch

Why it fails: VLAN mismatches usually occur on trunk links when the native VLAN IDs do not match on both ends. This configuration error generally results in a complete lack of connectivity for certain traffic or spanning-tree loops rather than the specific symptoms of high collision rates and slow throughput on a single host.

Cable length violation

Why it fails: Exceeding the maximum cable length for Ethernet, which is typically 100 meters for twisted-pair cabling, leads to signal attenuation and timing issues. While this can cause data errors and connectivity drops, it is a physical layer distance limitation rather than a logical configuration mismatch between the switch port and the host.

The DHCP server is on a different VLAN and the router is not forwarding DHCP requests.

Why it fails: If the DHCP server were on a different VLAN, a DHCP relay agent (ip helper-address) would be needed. However, the scenario states the DHCP server is operational and has addresses, but does not mention VLANs. The APIPA address indicates the workstation did not receive a DHCP response, which could be due to relay issues, but this is a less direct cause than a local link or VLAN misconfiguration on the switch port.

The workstation is configured with a static IP address in the 169.254.0.0/16 range.

Why it fails: If the workstation had a static IP in that range, it would be a misconfiguration, but the presence of a link light and a non-err-disabled port, along with the specific 169.254.x.x address, strongly suggests APIPA. A static assignment would not typically be overridden by APIPA, and the technician would need to verify the configuration method, but APIPA is the more common cause.

The workstation's NIC driver is outdated.

Why it fails: An outdated NIC driver could cause various connectivity issues, but it would not typically result in a specific APIPA address while still showing a link light. Driver problems often manifest as no link or intermittent connectivity. The consistent APIPA address indicates a DHCP failure, which is more directly related to network configuration than driver software.

Duplex mismatch between the switch and the server.

Why it fails: A duplex mismatch typically causes late collisions and runts, but CRC errors are more often associated with physical layer issues. While a duplex mismatch can cause collisions, late collisions are less common on Gigabit Ethernet because it uses full-duplex by default. CRC errors specifically point to signal corruption, making cabling a stronger suspect.

Spanning Tree Protocol blocking the interface.

Why it fails: STP blocking would place the port in a non-forwarding state, but it would not cause CRC errors or late collisions. STP operates at layer 2 and manages loops; it does not affect the physical integrity of frames. If STP were blocking, the port would not pass traffic at all, and error counters would not increment in this manner. This option misattributes a physical layer symptom to a logical topology mechanism.

Incorrect VLAN configuration on the switch port.

Why it fails: VLAN misconfiguration would cause connectivity issues such as inability to reach other devices, but it would not generate CRC errors or late collisions. Those counters are physical layer indicators. VLAN problems operate at layer 2 and do not corrupt frames on the wire. This option confuses logical configuration with physical transmission errors.

Perform a traceroute to the internet gateway.

Why it fails: Traceroute is a Layer 3 diagnostic tool that relies on successful ICMP or UDP communication. If the initial ARP resolution for the default gateway fails, the traceroute will time out immediately at the first hop, providing no additional visibility into the root cause of the local layer 2 connectivity failure.

Flush the DNS cache on the workstation.

Why it fails: DNS is a layer 7 protocol used for domain name resolution and has no impact on local network connectivity. Even if DNS resolution were failing, the workstation would still be able to ping the default gateway by its IP address, making this step irrelevant to troubleshooting layer 2 connectivity issues.

Reboot the switch connected to the workstation.

Why it fails: Rebooting network infrastructure is a disruptive and drastic troubleshooting measure that should only be performed after precise diagnosis. It provides no immediate technical insight into why a single workstation cannot communicate and may temporarily hide intermittent issues without addressing the underlying configuration or physical layer faults in the network.

show ip route

Why it fails: The IP routing table shows the paths to network destinations and is managed by layer 3 protocols. While useful for path selection issues, it does not provide information regarding physical layer errors or interface flapping, making it ineffective for diagnosing physical media or hardware-related intermittent connectivity problems in the network.

show ip arp

Why it fails: The ARP table links IP addresses to MAC addresses within the local network segment. While ARP issues can cause connectivity loss, they are related to layer 2 logical addressing and not physical layer integrity. Therefore, this command will not help identify physical errors or flapping ports on the switch.

show ip protocols

Why it fails: This command provides information about the active dynamic routing protocols and their status. It is used to troubleshoot layer 3 routing logic and neighbor adjacencies. Since it does not report interface-level statistics or physical status changes, it is irrelevant for diagnosing intermittent connectivity caused by layer 1 hardware issues.

The intermediate router is down.

Why it fails: If the traceroute reaches the last hop, it confirms that all intermediate routers are functional and passing traffic correctly. If an intermediate router were down, the traceroute would show a series of asterisks or time-out messages at the point where the path was broken, contradicting the scenario provided.

The default gateway is misconfigured.

Why it fails: If the default gateway were misconfigured, the traceroute would fail at the very first hop because the workstation would be unable to find the path to the destination network. Since the traceroute successfully reaches the final hop, the routing infrastructure is clearly operating as expected.

The DNS server is down.

Why it fails: Traceroute and ping rely on IP connectivity, not DNS resolution, assuming the destination IP address was used. If DNS were the issue, the traceroute would fail to resolve the hostname but would still be able to proceed if the IP address was known. This is not the primary issue.

Cisco DNA Center.

Why it fails: Cisco DNA Center is a centralized management and automation platform. While it provides high-level telemetry and health dashboards, it is not a granular tool for performing real-time packet capture or deep-dive analysis of traffic distribution on a specific network segment to identify broadcast traffic patterns effectively.

SNMP Manager.

Why it fails: SNMP is used for monitoring device health, CPU usage, and interface traffic levels. While it can show high bandwidth utilization, it does not provide the packet-level visibility needed to distinguish between legitimate high traffic and broadcast-induced congestion, making it less effective for identifying the root cause of broadcast storms.

TDR cable tester.

Why it fails: A Time Domain Reflectometer (TDR) is a physical layer diagnostic tool used to identify breaks, shorts, or impedance mismatches in copper cabling. It is completely unaware of network traffic patterns or frame types, and therefore cannot be used to diagnose logical issues like broadcast traffic or network congestion.

The interface has a duplex mismatch.

Why it fails: A duplex mismatch would manifest as an increase in collision counts or CRC errors on the interface. Since the error count is zero, the interface is successfully processing frames, but it is simply overwhelmed by the volume of traffic relative to its configured speed capacity.

The cable is faulty and causing retransmissions.

Why it fails: A faulty cable would increase the error rate and potentially cause the link state to flap or drop. Because the status is 'up/up' and there are zero errors, the physical integrity of the cable is confirmed to be healthy, ruling out physical layer problems as the cause.

The interface MTU is configured incorrectly.

Why it fails: Incorrect MTU settings typically lead to fragmented packets or dropped packets with 'MTU exceeded' errors. While this causes performance issues, it does not explain the discrepancy between input traffic and bandwidth capacity shown in the interface statistics, which is the primary indicator of the performance bottleneck here.

To establish a TCP session for data transfer.

Why it fails: TCP is a connection-oriented transport protocol used for reliable data transmission, requiring a three-way handshake. ICMP is a connectionless network layer protocol and does not establish sessions, nor does it provide the reliability mechanisms that TCP requires for data transfer applications in a network environment.

To resolve a hostname to an IP address.

Why it fails: Hostname resolution is the function of the DNS protocol. ICMP is entirely dependent on IP addresses and cannot translate domain names. Therefore, it is incapable of resolving hostnames, making it an inappropriate tool for any task that requires querying a directory or mapping names to addresses.

To encrypt packets for secure communication.

Why it fails: ICMP is a plain-text protocol designed for diagnostic and management purposes. It lacks any built-in encryption, authentication, or security features. Using ICMP for secure communication is impossible, as the data is easily intercepted and read by anyone with access to the network path between the two devices.

Check the ARP table for excessive entries.

Why it fails: While a large ARP table can consume memory, it does not directly correlate with high CPU usage on a switch. CPU spikes are usually related to packet processing or management tasks. Therefore, checking the ARP table is not the most effective way to identify the source of CPU stress.

Clear the interface statistics.

Why it fails: Clearing interface statistics removes the historical data needed to analyze the traffic patterns causing the congestion. This makes it impossible to perform a post-mortem analysis of the traffic that triggered the high CPU usage, making it an counter-productive step in troubleshooting a performance issue.

Disable spanning-tree on all ports.

Why it fails: Disabling spanning-tree is extremely dangerous and can lead to immediate network-wide broadcast storms. It is not a legitimate diagnostic tool for troubleshooting high CPU usage and would likely exacerbate the problem by creating loops, which would increase CPU load even further due to the processing of redundant traffic.

Check the switch interface status.

Why it fails: The switch interface status tells you if the physical link is up or down. While this is important, it does not tell you if the workstation has been assigned a valid IP address by DHCP or static configuration. It only confirms that the physical layer is connected.

Perform a traceroute to the local gateway.

Why it fails: A traceroute to the local gateway is meant to test path reliability. If the PC does not have a valid IP address, it will not be able to generate the packets necessary for a traceroute, making this test useless until the basic IP addressing has been verified first.

Reset the switch configuration.

Why it fails: Resetting a switch is a destructive action that will cause significant network downtime. It is never the correct step for troubleshooting a single workstation's IP addressing issue. This would impact every other device connected to the switch and is completely disproportionate to the problem of a single host.

The interface is shut down.

Why it fails: The routing table shows the interface as directly connected and active ('C'). If the interface were shut down, it would not appear as a connected route in the routing table. Therefore, the interface status is not the reason for the lack of internet connectivity in this scenario.

The subnet mask is incorrect.

Why it fails: The subnet mask is displayed correctly as a /24 network. There is no indication of overlapping or conflicting subnets in the routing table that would prevent connectivity. The issue is purely the lack of an exit path for external traffic, not the local configuration of the subnet itself.

The router has no IP address assigned.

Why it fails: The routing table shows a 'Local' (L) route for 192.168.1.1/32, which indicates that the router has successfully assigned this IP address to its interface. Therefore, the router has an IP address, and this is not the cause of the failure to route traffic to the internet.

To act as a physical bridge between two VLANs.

Why it fails: Loopback interfaces are purely logical and have no physical port or cabling associated with them. They cannot bridge traffic between physical interfaces or VLANs. Bridging is the function of a switch or a router configured with inter-VLAN routing, not a loopback interface.

To increase the total bandwidth of the router.

Why it fails: Loopback interfaces do not have bandwidth and do not contribute to the forwarding capacity of a router. They are virtual entities used for control plane purposes. They do not process traffic for the data plane, so they cannot be used to increase link speed or network throughput.

To provide power over Ethernet to connected devices.

Why it fails: Power over Ethernet (PoE) is a hardware feature provided by physical switches to supply electricity to IP phones or cameras via copper cabling. A loopback interface is entirely software-based and cannot provide physical electrical output, making it impossible for it to perform any hardware power delivery functions.

show cable status

Why it fails: There is no 'show cable status' command in the Cisco IOS command line interface. This is not a valid syntax and would result in an error message. Technicians must use the correct TDR-based diagnostic commands to verify the integrity of the physical cabling on a switch port.

ping -t <ip>

Why it fails: The ping command with the -t flag (on Windows) or default infinite ping (on some systems) only tests logical connectivity and latency. It provides absolutely no information about the physical integrity of the cable, making it useless for diagnosing electrical shorts or opens in the underlying copper cabling infrastructure.

show interfaces summary

Why it fails: This command provides an overview of interface states, bandwidth, and traffic statistics. It is used to monitor interface performance and capacity but does not perform physical electrical tests on the cabling. It cannot detect shorts, opens, or cable length, making it an ineffective tool for diagnosing physical layer cabling faults.

Default Gateway

Why it fails: Incorrectly configured default gateways typically prevent traffic from leaving the local subnet entirely. Since the user can reach internal resources via IP address, the gateway is likely functioning for local routing. If the gateway were wrong, the user would lose access to all remote segments, not just services accessed by their domain names.

DHCP

Why it fails: Dynamic Host Configuration Protocol handles the automatic assignment of IP addresses to devices. Since the device currently has an IP address and can communicate with internal resources, DHCP has already successfully completed its job. While DHCP provides the DNS server address, the protocol itself is not responsible for the name resolution failure.

ARP

Why it fails: Address Resolution Protocol maps Layer 3 IP addresses to Layer 2 MAC addresses on the local segment. If ARP were failing, the user would be unable to communicate with the server even when using the direct IP address. The successful connection via IP indicates that ARP is functioning correctly for the local network segment.