Hard Difficulty Questions

Smurf attack

Why it fails: A Smurf attack spoofs the victim's address and pings a broadcast address, so replies come from many hosts, not from private 10.0.0.0/8 sources arriving externally. It is tempting because Smurf uses spoofed source addresses, making it correct when logs show ICMP echo replies flooding from a subnet's broadcast range.

SYN flood

Why it fails: A SYN flood sends TCP SYN packets with spoofed sources, but the tell-tale is half-open connections and SYN flags, not private-range source addresses on the external interface. It is tempting because SYN floods are volumetric denial-of-service attacks, making them correct when logs show many incomplete TCP handshakes.

DNS amplification

Why it fails: DNS amplification spoofs the victim's address as the query source, so packets arrive from DNS resolvers, not with private 10.0.0.0/8 sources on the external interface. It is tempting because amplification floods a target with reflected traffic, which is the correct answer when logs show huge responses from public resolvers.

Use static routes instead of OSPF

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

SSL VPN with client certificate authentication

Why it fails: Client certificate authentication supplies only one factor — something the user has — so it cannot satisfy the two-factor requirement, and it performs no patch-level posture check. It is tempting because certificate-based SSL VPNs are strong for device authentication, but the scenario demands a second factor plus compliance verification.

IPsec VPN using preshared keys

Why it fails: IPsec preshared keys authenticate the tunnel itself, providing neither per-user two-factor authentication nor endpoint patch compliance checks. It is tempting because IPsec is a legitimate remote-access VPN, but it would fit a site-to-site tunnel where device identity, not user MFA and posture, is the requirement.

NAC integrated with a reverse proxy

Why it fails: NAC enforces endpoint posture, but pairing it with a reverse proxy provides no VPN tunnel and no two-factor authentication mechanism for remote users. It is tempting because NAC genuinely delivers patch-compliance checking, yet the reverse proxy cannot terminate remote-access VPN sessions or verify a second factor.

Transport mode

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

Port security

Why it fails: Port security limits the number of MAC addresses learned on a switch port, but the attacking workstation uses one MAC, so ARP spoofing proceeds. It suits blocking rogue switches or MAC flooding, not forged ARP replies from a legitimate port.

DHCP snooping

Why it fails: DHCP snooping builds a trusted-port binding table of MAC-to-IP pairs to block rogue DHCP servers and DHCP starvation; it does not inspect ARP traffic. Dynamic ARP Inspection, which validates ARP packets against that binding table, is the mechanism that stops ARP spoofing. DHCP snooping is tempting because DAI depends on its database.

MAC address filtering

Why it fails: MAC address filtering permits or denies specific hardware addresses but cannot stop a host already allowed on the port from flooding forged ARP replies; the attack continues. It suits restricting which known devices may attach, not containing an insider already connected.

DNS amplification attack

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

MAC flooding attack

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

ARP spoofing

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

DNS poisoning

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

1

Why it fails: A single Layer 3 broadcast domain would require all VLANs to share one routed subnet, which the 802.1Q trunk and per-VLAN router subinterfaces prevent. Each subinterface on VLANs 10, 20 and 30 creates its own broadcast domain, so one is incorrect.

2

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

4

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

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

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

A DNS server

Why it fails: DNS resolves domain names to IP addresses but does not authenticate users or devices. It is not part of the 802.1X process.

A DHCP server

Why it fails: DHCP assigns IP addresses to clients, but it does not perform authentication. 802.1X typically works before DHCP to ensure only authenticated devices get network access.

A Kerberos server

Why it fails: Kerberos is used for authentication in Windows domains but operates at the application layer. 802.1X uses EAP (Extensible Authentication Protocol) over RADIUS, not directly Kerberos. While Active Directory uses Kerberos for domain authentication, the network-level 802.1X authentication is mediated by RADIUS.