Hard Difficulty Questions

Use static routes instead of OSPF

Why wrong: Using static routes instead of a dynamic routing protocol like OSPF fundamentally prevents the network from adapting to topology changes automatically. Static routes are manually configured and remain fixed, offering no inherent mechanism for detecting link failures or automatically rerouting traffic. If a link fails along a statically defined path, traffic will be black-holed until manual intervention, which is the opposite of improving convergence and network resilience.

Increase OSPF hello and dead timers

Why wrong: Increasing OSPF hello and dead timers directly lengthens the time it takes for OSPF to detect a neighbor or link failure. The hello timer dictates how frequently a router sends hello packets to its neighbors, while the dead timer specifies how long a router waits to receive a hello packet before declaring a neighbor down. By extending these intervals, OSPF will wait longer to identify a problem, delaying the initiation of the SPF algorithm and consequently slowing down the network's overall convergence time after an event.

Configure all routers in a single OSPF area

Why wrong: Configuring all routers within a single OSPF area, especially in a large network, creates a monolithic routing domain where every router must maintain a complete Link-State Database (LSDB) for the entire network. Any topology change, such as a link failure or a new router, triggers a re-calculation of the Shortest Path First (SPF) algorithm on every router in that area. This extensive computation consumes significant CPU resources and increases the time required for the network to converge, directly impeding the goal of faster convergence.

Transport mode

Why wrong: Transport mode encrypts only the payload of the original IP packet, leaving the original IP header unencrypted and visible. This means that the source and destination IP addresses of the communicating hosts are exposed to anyone monitoring the network traffic. While suitable for end-to-end host-to-host encryption, Transport mode is inappropriate for site-to-site VPNs, as it fails to conceal the network topology and internal addressing of the connected branches.

AH only

Why wrong: The Authentication Header (AH) protocol within IPsec provides data integrity, data origin authentication, and anti-replay services by hashing the packet and adding an integrity check value. However, AH explicitly does not offer any encryption or confidentiality for the packet's contents. Therefore, using AH only would not encrypt the sensitive data traversing the VPN tunnel, failing to meet the fundamental requirement of a secure site-to-site VPN to protect information from eavesdropping.

ESP only

Why wrong: Encapsulating Security Payload (ESP) is an IPsec protocol that provides confidentiality (encryption), data origin authentication, data integrity, and anti-replay services. However, simply selecting 'ESP only' does not specify the crucial encapsulation method required for a site-to-site VPN. ESP can operate in either transport or tunnel mode, and for a site-to-site connection, the entire original packet, including its header, must be encapsulated and encrypted, which is a function of tunnel mode, not solely the ESP protocol itself.

DNS amplification attack

Why wrong: A DNS amplification attack is a type of distributed denial-of-service (DDoS) attack that leverages open DNS resolvers to flood a target with large volumes of UDP response traffic. Attackers send small DNS queries with a spoofed source IP (the victim's) to numerous DNS servers, which then reply with much larger responses to the victim. Firewall logs would primarily show a high volume of incoming UDP DNS responses, not a flood of TCP SYN packets, as the attack vector is entirely different.

ARP spoofing attack

Why wrong: ARP spoofing is a Layer 2 attack where an attacker sends forged Address Resolution Protocol (ARP) messages to a local area network. This manipulates the MAC address-to-IP address mappings in device ARP caches, redirecting traffic through the attacker's machine. Such an attack would primarily generate ARP traffic, not a flood of TCP SYN packets visible in firewall logs, as its goal is traffic interception, not connection exhaustion.

Man-in-the-middle attack

Why wrong: A Man-in-the-Middle (MITM) attack involves an attacker secretly relaying and possibly altering the communication between two parties who believe they are directly communicating. While a MITM attacker intercepts network traffic, the primary objective is eavesdropping, data manipulation, or session hijacking, not overwhelming a server with connection requests. Therefore, firewall logs would not typically show a massive influx of SYN packets originating from many different sources as a characteristic signature of this type of attack.

Port security

Why wrong: Port security restricts the number of MAC addresses per port but does not inspect ARP packets.

DHCP snooping

Why wrong: DHCP snooping filters rogue DHCP servers and builds a binding table, but does not directly validate ARP traffic.

MAC address filtering

Why wrong: MAC filtering controls which MAC addresses are allowed, but does not prevent ARP spoofing.

MAC flooding attack

Why wrong: MAC flooding attacks target the switch's MAC address table, not DHCP servers.

ARP spoofing

Why wrong: ARP spoofing involves sending fake ARP replies to associate an attacker's MAC with an IP address, not DHCP exhaustion.

DNS poisoning

Why wrong: DNS poisoning corrupts DNS cache to redirect traffic, unrelated to DHCP exhaustion.

Bad Ethernet cable

Why wrong: While a bad cable can cause FCS errors, the specific scenario of one side manually set and the other auto-negotiating strongly points to a duplex mismatch.

Speed mismatch

Why wrong: The link is up, indicating both sides are likely at the same speed (100 Mbps). Speed mismatch would prevent the link from coming up.

Printer driver issues

Why wrong: Driver issues would not cause physical layer errors like FCS errors; they are a Layer 2/3 issue.

1

Why wrong: Incorrect. One broadcast domain would be the case if all devices were on the same subnet.

2

Why wrong: Incorrect. Two broadcast domains is not accurate given the three routed subinterfaces.

4

Why wrong: Incorrect. This mistakenly counts VLAN 99, which lacks a router subinterface, as a Layer 3 broadcast domain.

A

Why wrong: 10 Gigabit Ethernet is widely supported and not the cause of this specific issue.

B

Why wrong: While a faulty fiber cable could cause general failures, the pattern of small transfers working and large transfers failing points to an MTU issue.

D

Why wrong: TCP window size affects throughput but not the ability to transfer large files at all; small transfers would also fail if window size were severely misconfigured.

Virtual IP (VRRP/HSRP)

Why wrong: Incorrect. VRRP/HSRP provide first-hop gateway redundancy for routers, not for server NIC failover. They operate at Layer 3 and would require the server to act as a router, which is not the intended use.

Spanning Tree Protocol (STP)

Why wrong: Incorrect. STP prevents loops in a switched network but does not provide load balancing or server failover.

Port mirroring

Why wrong: Incorrect. Port mirroring duplicates traffic for monitoring purposes and does not offer any failover or load balancing capability.

The router's ip helper-address is configured on the wrong interface

Why wrong: The scenario states the helper address is on the VLAN 10 interface; if it were on the wrong interface, users would not reach the DHCP server at all, but they can ping the server from the router.

The switch port connecting users is configured as a trunk instead of an access port

Why wrong: A trunk port would still allow traffic in VLAN 10, but if misconfiguration caused the user to be in the wrong VLAN, they might not be in VLAN 10. However, they could still likely reach the DHCP relay if routing works. A trunk misconfiguration is less likely to cause APIPA when the relay is working.

The router's ACL is blocking DHCP offers from the server

Why wrong: If an ACL were blocking DHCP replies, the router would still receive them but drop them; however, the users would not get replies, leading to APIPA. But since the helper address is configured, the ACL would need to explicitly block UDP ports 67/68, which is less common than a missing scope.

Man-in-the-middle attack

Why wrong: A man-in-the-middle (MITM) attack involves an attacker secretly relaying and potentially altering the communication between two parties who believe they are directly communicating with each other. This attack focuses on intercepting, eavesdropping, or manipulating data in transit, often through techniques like ARP spoofing or DNS poisoning. Sending a flood of SYN packets, as described, is a direct denial-of-service technique, not an interception or relaying method characteristic of a MITM attack.

DDoS amplification attack

Why wrong: A DDoS amplification attack involves an attacker sending small, specially crafted requests to legitimate, open third-party servers (like DNS or NTP servers) with the victim's spoofed IP address as the source. These servers then respond with significantly larger replies directed at the victim, amplifying the attack traffic volume. While a SYN flood is a denial-of-service attack, it directly sends SYN packets to the victim and does not rely on leveraging intermediate services to generate larger responses, thus it is not an amplification technique.

Smurf attack

Why wrong: A Smurf attack is a type of distributed denial-of-service (DDoS) attack that leverages ICMP (Internet Control Message Protocol) echo requests. The attacker sends ICMP echo requests to a network's broadcast address, spoofing the source IP address to be that of the intended victim. All hosts on the broadcast network then reply to the victim's spoofed IP with ICMP echo replies, overwhelming the victim with a flood of traffic. The scenario explicitly describes TCP SYN packets, not ICMP, making a Smurf attack an incorrect classification.

Increase the server's TCP connection backlog.

Why wrong: Increasing the server's TCP connection backlog merely expands the queue for half-open connections awaiting the final ACK. While this might slightly delay the point of exhaustion, it does not fundamentally alter the server's vulnerability to a sustained SYN flood. The server still dedicates finite memory and processing resources to each entry in that backlog, meaning a sufficiently large or prolonged attack will inevitably fill even an expanded queue, leading to service degradation.

Enable bogon filtering on the perimeter firewall.

Why wrong: Bogon filtering on a perimeter firewall blocks traffic originating from IP addresses that are reserved for private networks or are currently unallocated on the internet. While some SYN flood attacks utilize spoofed source IP addresses, many of these spoofed addresses are not bogons, rendering this defense largely ineffective against a sophisticated SYN flood. This technique primarily aims to prevent traffic from clearly invalid sources, not to mitigate resource exhaustion from a high volume of seemingly valid, yet malicious, connection attempts.

Deploy an intrusion prevention system (IPS) with signature detection.

Why wrong: Deploying an Intrusion Prevention System (IPS) with signature detection can identify and potentially block known SYN flood patterns. However, an IPS typically operates at a higher layer and requires more computational resources per packet than simpler network devices or server-side mitigations. In the face of a high-volume SYN flood, the IPS itself can become a bottleneck, struggling to process the immense traffic volume, leading to performance issues or even becoming overwhelmed before the attack traffic reaches the server.

/52

Why wrong: Selecting a /52 prefix for subnetting from a /48 global routing prefix allocates only 4 bits for subnet identification (52 - 48 = 4). This results in 2^4, or 16, available subnets. This quantity is significantly less than the required 250 subnets, rendering /52 an inadequate choice for the specified network design.

/64

Why wrong: A /64 prefix uses 16 bits for subnetting (48+16=64), providing 65,536 subnets. While it works, it wastes many subnet IDs and is not minimal for 250 subnets. Also, /64 is typically used for end-user subnets, not as a subnetting strategy from a /48.

/60

Why wrong: Utilizing a /60 prefix for subnetting from a /48 global routing prefix dedicates 12 bits for subnet identification (60 - 48 = 12). This provides 2^12, or 4,096, distinct subnets. While this technically satisfies the requirement for 250 subnets, it represents a substantial over-allocation and inefficient use of the available address space, making it a less optimal choice compared to a /56.

The syslog server is using the wrong protocol (TCP instead of UDP)

Why wrong: While modern syslog implementations like Syslog-ng or rsyslog can be configured to use TCP for reliable log delivery, the traditional and default protocol for syslog is UDP. If the router is configured to send syslog via UDP, and the server is exclusively listening for TCP connections on port 514, the UDP packets from the router would simply be ignored by the server's syslog daemon. However, a server misconfiguration of listening protocol is less common than an intermediate firewall blocking the standard UDP port, especially when the router is sending via the default UDP.

The syslog service on the server is not running

Why wrong: If the service were not running, the server would not respond, but that would not prevent the router from sending the messages; the server simply would not log them. The lack of receipt indicates a delivery problem.

The router's clock is not synchronized with the server

Why wrong: A lack of clock synchronization between the router and the syslog server primarily affects the accuracy and consistency of timestamps within the log messages themselves. While crucial for forensic analysis, correlation of events, and proper auditing, incorrect time settings do not impede the actual transmission or reception of syslog packets. The router would still generate and send syslog messages, and the server would still receive and log them, albeit with potentially inaccurate timestamps. This issue impacts data utility, not network transport.

LLDP

Why wrong: Link Layer Discovery Protocol (LLDP) is a vendor-neutral Layer 2 protocol used by network devices to advertise their identity, capabilities, and port information to directly connected neighbors. It facilitates network topology discovery and troubleshooting by allowing devices to learn about their immediate connections. While useful for mapping adjacent devices, LLDP does not provide comprehensive operational metrics, configuration settings, or status information for the device itself or for devices beyond the immediate link, making it unsuitable for broad network monitoring.

NetFlow

Why wrong: NetFlow (and similar technologies like IPFIX or sFlow) is designed to collect and export IP traffic statistics, such as source/destination IP addresses, ports, protocols, and byte counts, from network devices. It provides insights into *who* is communicating with *whom* and *how much* data is being transferred, which is crucial for bandwidth monitoring and security analysis. However, it does not provide direct device operational metrics like CPU utilization, interface status, or configuration details, which are typically collected via SNMP.

Syslog

Why wrong: Syslog is a standard protocol for sending system log or event messages to a central logging server. Network devices use Syslog to report events such as interface state changes, security alerts, or authentication failures, providing a chronological record of device activity. While logs can indicate operational issues, Syslog is unstructured text data and is not designed for polling specific, real-time performance metrics or retrieving configuration parameters in a programmatic, queryable format like SNMP. It's reactive event reporting, not proactive metric collection.

The OSPF Hello and Dead intervals are mismatched

Why wrong: OSPF routers exchange Hello packets to discover neighbors and maintain adjacency. For a neighbor relationship to progress to the Two-Way state, the Hello and Dead intervals configured on the interfaces must precisely match. If these timers are mismatched, routers will receive Hello packets but will not acknowledge them as valid, preventing them from seeing each other in their respective neighbor lists. This condition typically causes the adjacency to remain stuck in the Init state, failing to advance to Two-Way or subsequent states like ExStart.

The OSPF area IDs are different

Why wrong: OSPF routers must belong to the same area to establish a neighbor relationship. If the OSPF area IDs are different on the interfaces attempting to form an adjacency, the routers will not even recognize each other as potential neighbors. This mismatch causes the routers to drop each other's Hello packets, preventing them from progressing beyond the Down state and certainly not reaching the ExStart state. Adjacency formation is fundamentally dependent on matching area IDs.

The network type is misconfigured (e.g., one side is broadcast, the other is point-to-point)

Why wrong: A mismatch in OSPF network types, such as one interface configured for broadcast and the other for point-to-point, can lead to significant issues in neighbor discovery and Designated Router (DR)/Backup Designated Router (BDR) election processes. While this misconfiguration can prevent full adjacency, it typically allows the routers to progress beyond the ExStart state, often getting stuck in the Exchange or Loading states due to problems with DR election or LSA exchange mechanisms. The fundamental neighbor discovery and initial DBD exchange usually succeed, unlike an MTU mismatch.

The backup link has a lower OSPF cost than the primary link.

Why wrong: While it is true that OSPF will always prefer a path with a lower cost, stating that 'the backup link has a lower OSPF cost than the primary link' describes the outcome rather than the root cause from the primary link's perspective. The issue arises because the *intended primary* link's cost is comparatively higher, leading OSPF to select the backup path. This option merely reiterates the observed behavior without pinpointing the specific configuration error on the primary link that led to this preference.

The reference bandwidth is set to 1 Gbps on the primary router.

Why wrong: OSPF calculates interface cost using the formula 'reference bandwidth divided by interface bandwidth'. The default reference bandwidth is 100 Mbps. If the reference bandwidth on the primary router were set to 1 Gbps (1000 Mbps), a 1 Gbps primary link would have a cost of 1 (1000/1000). A typical 100 Mbps backup link would then have a cost of 10 (1000/100). This configuration would cause the primary link to be preferred due to its lower cost, which directly contradicts the problem statement where traffic is flowing over the backup link.

The bandwidth command is misconfigured on the backup interface.

Why wrong: The `bandwidth` command on an interface directly influences its OSPF cost, as OSPF uses this value in its cost calculation. While a misconfiguration on the backup interface could certainly alter its OSPF cost, the central problem described is the *primary* link not being preferred. If the backup interface's bandwidth were misconfigured in a way that made its OSPF cost lower than the primary, it would contribute to the issue. However, the most direct cause for the primary link being ignored is a higher OSPF cost configured on the primary link itself, making it less attractive than the backup.

Check the DNS server for the phone's name resolution

Why wrong: Checking the DNS server for phone name resolution is less likely to resolve intermittent call drops during an active conversation. DNS is primarily utilized during the initial call setup phase to resolve FQDNs (Fully Qualified Domain Names) of call managers or other endpoints to their respective IP addresses. Once a call is established and the media stream is flowing, DNS is generally no longer actively involved, meaning ongoing resolution issues would not typically cause intermittent drops in an already connected call.

Replace the patch cables from the phones to the switches

Why wrong: Replacing patch cables from phones to switches is generally not the primary solution for intermittent call drops without other symptoms. Physical cabling issues typically manifest as complete link failures, excessive Layer 1/2 errors such as CRC errors, or persistent connectivity problems that are not intermittent. While a severely damaged cable could cause sporadic issues, intermittent call drops during an otherwise stable connection are more indicative of packet loss due to network congestion or misconfiguration at higher layers, rather than a fundamental physical link integrity problem.

Increase the DHCP lease time for the phones

Why wrong: Increasing the DHCP lease time for phones addresses how frequently a device renews its IP address, not the quality of an active voice call. A short lease time might lead to frequent renewal attempts or potential IP conflicts if not managed properly, possibly causing temporary connectivity loss during the renewal process. However, it does not directly influence the quality of voice traffic or cause intermittent packet loss during an active, established conversation, as the IP address remains stable for the duration of the lease.

Notified all users of the maintenance window.

Why wrong: Notifying all users of the maintenance window is an essential administrative and communication practice to manage expectations and inform stakeholders about potential service interruptions. However, this action does not provide any technical mechanism to restore the switch's functionality or configuration if the upgrade process fails. While crucial for user satisfaction and operational transparency, it offers no safeguard against technical issues that might arise during the firmware or configuration update.

Disconnected all redundant links.

Why wrong: Disconnecting all redundant links, while sometimes performed to simplify network topology during major changes or to prevent potential loops during specific reconfigurations, does not directly aid in restoring a switch after a failed upgrade. This action primarily affects network path redundancy and Spanning Tree Protocol (STP) convergence. It does not provide a means to recover the switch's corrupted firmware, restore its previous configuration, or revert to a stable operating state if the upgrade process itself encounters an error.

Set the switch to boot from an alternative image.

Why wrong: Setting the switch to boot from an alternative image is a potential recovery mechanism, but it is not a primary preparatory step for ensuring full restoration to the previous state after a failed upgrade. This action only dictates which image the switch attempts to load upon reboot. If the alternative image is not the original, known-good firmware, or if the configuration itself becomes corrupted during the upgrade, simply pointing to another image will not guarantee a complete rollback to the exact pre-upgrade operational state. A comprehensive backup is still required for true restoration.

Server B's firewall is blocking outgoing ICMP

Why wrong: If Server B's firewall blocked outgoing ICMP, it would not send the ping request, and Server A would not receive the ping attempt. The symptom would be 'destination unreachable' from Server B, but Server A would see no request. However, Server A can ping Server B, so Server B replies are allowed in. Blocking only outgoing requests on Server B would result in a different failure (Server B cannot initiate pings, but could still receive them). Given the symptom, blocking incoming on Server A is more common.

The cable connecting Server A is faulty

Why wrong: A faulty network cable, whether due to a broken wire, poor termination, or excessive length, would typically disrupt the physical layer connectivity for Server A. Such an issue would manifest as intermittent packet loss, complete link failure, or very high error rates, affecting communication in *both* directions. It would not selectively block only incoming ICMP echo requests while allowing outgoing ICMP traffic and its corresponding replies, which is the specific symptom described.

There is a duplex mismatch on Server B's switch port

Why wrong: A duplex mismatch occurs when one device operates in full-duplex mode while the other operates in half-duplex mode. This scenario leads to severe network performance degradation, characterized by high collision rates, late collisions, and significant frame errors on the half-duplex side, and potentially excessive retransmissions on the full-duplex side. While it severely impacts communication, it typically results in poor performance or intermittent connectivity in *both* directions, not a complete, consistent one-way failure of a specific protocol like ICMP.