OSPF practice questions

Standard IPv4 ACLs use numbers in the range 100-199.

Why wrong: Standard IPv4 ACLs are numbered in the ranges 1–99 and 1300–1999, not 100–199. The number range 100–199 is explicitly reserved for extended numbered ACLs, which evaluate source and destination IP addresses, protocol, and port numbers. Misidentifying 100–199 as standard ACL numbers confuses the ACL type and its underlying matching logic.

Standard IPv4 ACLs filter only the source IP address and are best placed close to the source to be most effective.

Why wrong: Standard ACLs indeed filter only on the source IP address, but that limited matching capability requires them to be placed as close to the destination as possible, not the source. If placed near the source, a standard ACL entry that denies a particular source would block that source's traffic to all destinations, including legitimate ones. Positioning near the destination limits the ACL's impact to the intended target network, avoiding accidental collateral denial.

Numbered ACLs allow individual access control entries (ACEs) to be deleted without removing the entire ACL.

Why wrong: Numbered ACLs do not permit deletion of an individual access control entry; to remove one ACE, the entire ACL must be deleted and re-entered without that entry. Named ACLs, in contrast, assign sequence numbers to each ACE, allowing selective deletion, insertion, and resequencing without recreating the full list. This operational limitation of numbered ACLs applies to both standard and extended numbered variants and is a common source of configuration errors.

The interface is administratively down.

Why wrong: The interface status in the output reads 'up, line protocol is up', indicating that the interface is fully operational at both Layer 1 and Layer 2. An administratively down interface would instead show 'administratively down, line protocol is down' and would not generate any IPv6 traffic, including Router Advertisements. Since the router is actively advertising and the link-local address is present, the interface is clearly not shut down or disabled.

The MAC address of the interface is invalid, preventing EUI-64 from generating a proper address.

Why wrong: The link-local address FE80::21A:2BFF:FE3C:4D5E shown in the output is derived from the interface MAC address using EUI-64, which inserts FFFE in the middle and flips the U/L bit. The presence of this valid link-local address proves the MAC address is not invalid and EUI-64 generation succeeded. An invalid or all-zero MAC would prevent IPv6 from generating any link-local address, but the output clearly displays a properly formed one, so this option cannot be the cause.

The router is not sending Router Advertisements, so hosts cannot autoconfigure.

Why wrong: The output explicitly states 'ND router advertisements are sent every 200 seconds', which confirms the router is actively sending ICMPv6 Router Advertisements on this interface. Hosts would therefore be able to perform stateless address autoconfiguration (SLAAC) and learn the default router. However, the problem is that hosts cannot reach the router's own link-local address, which points to a missing or incorrectly configured IPv6 address on the router itself, not to a lack of RA messages.

Configure only a DNS server of 10.10.10.5.

Why wrong: Configuring only a DNS server of 10.10.10.5 gives the workstation the ability to resolve hostnames into IP addresses, but name resolution does not provide any forwarding path for traffic destined outside the local subnet. The workstation's routing table has no default route, so any packet with a destination IP outside 10.10.10.0/24 is dropped as unreachable. Even though the DNS server is reachable on the same subnet, the host still cannot reach the server at 10.10.20.x because there is no gateway to route that traffic. Thus, DNS alone is insufficient for inter-subnet communication.

Change the subnet mask to 255.255.0.0 to allow communication across subnets.

Why wrong: Altering the workstation's subnet mask to 255.255.0.0 (/16) would make it assume that all 10.10.x.x addresses are within the same local broadcast domain. As a result, it would attempt to resolve destinations like 10.10.20.5 via ARP rather than forwarding them to a router, but ARP is a Layer 2 broadcast that cannot cross a router. This not only fails to provide a path to other subnets but also breaks routing from the router's perspective, since the router's interface is still configured with a /24 mask and will treat the host's /16 view as a conflicting route. The proper solution requires a Layer 3 gateway, not an expanded subnet mask.

Configure a default gateway of 10.10.20.1 and a DNS server of 10.10.10.5.

Why wrong: This configuration fails because a default gateway must be directly reachable on the same IP subnet as the host. The gateway 10.10.20.1 is on the 10.10.20.0/24 network, while the workstation is on 10.10.10.0/24, so the host cannot ARP for it and will not be able to send any frames to that gateway. Even if the DNS server 10.10.10.5 is correct, the workstation will still be unable to communicate with any remote subnet because its default route points to an unreachable next hop. The host essentially has no valid gateway, so all non-local traffic is discarded.

Check the DHCP server logs to see if it is receiving Discover messages.

Why wrong: Checking the DHCP server logs for Discover messages is premature in this scenario. Because the DHCP server resides on a different subnet than the clients, server-side logs will only show Discover packets if the router's VLAN 20 interface has an IP helper-address configured to forward broadcast DHCP requests. If the helper-address is missing, the router drops the broadcast at the VLAN boundary, and the server never sees any Discover traffic—so the absence of such messages in the logs would merely confirm the relay misconfiguration, not diagnose it. This step is valid only after confirming that the relay configuration is correct, and it wastes troubleshooting time by skipping the most fundamental cause.

Attempt to ping the DHCP server's IP address from the host's APIPA address.

Why wrong: The host's APIPA address (169.254.x.x) is a link-local address. Without a default gateway or a routable IP, pinging an address on a different subnet will not work, even if the DHCP server is reachable. This test does not confirm DHCP functionality and is not a standard troubleshooting step for DHCP failures.

Restart the DHCP service on the server and recheck the host.

Why wrong: Restarting the DHCP service is a disruptive action and should not be the first step, especially when the root cause likely lies in the network configuration (missing relay). It does not address the underlying issue and may cause unnecessary downtime.

Deploy a predictive analytics model to forecast future traffic volumes and adjust thresholds accordingly.

Why wrong: Predictive analytics models apply time-series forecasting to anticipate future traffic loads (e.g., bandwidth utilization during peak hours) and proactively adjust thresholds. This approach is inherently prospective—it does not compute a real-time baseline of 'normal' behavior across multiple features, so it cannot distinguish a genuine security anomaly from a routine but irregular spike. Adjusting thresholds based on forecasts may actually increase false positives when the forecast is inaccurate, and it still lacks the per-flow or per-host behavioral comparison needed to suppress alert noise.

Apply intent-based networking to automatically enforce security policies based on high-level business intent.

Why wrong: Intent-based networking (IBN) automates the translation of high-level business policies into concrete device configurations and continuously validates that the network state meets that intent. However, IBN operates on policy assurance and configuration management; it does not ingest traffic telemetry to learn what normal traffic looks like, nor does it classify live traffic as benign or malicious. False positive alerts from an existing NMS or IDS remain untouched because IBN does not add a layer of statistical or behavioral analysis to the monitoring pipeline—it simply enforces and verifies the intended state.

Use deep packet inspection to examine all traffic and create static rules for known threats.

Why wrong: Deep packet inspection (DPI) examines packet payloads against a signature database to identify known attack patterns, then applies static rules (e.g., drop or alert). While DPI is effective for known exploits, it is blind to behavioral anomalies that have no matching signature—zero-day attacks or subtle deviations in traffic volume, latency, or flow topology. Because the rules are static, they cannot adapt to evolving baseline behavior, so legitimate traffic that coincidentally resembles a signature (e.g., a malformed but benign packet) triggers false positives, and genuinely abnormal traffic without a signature goes unnoticed.

The default gateway must be removed from the DHCP scope.

Why wrong: Removing the default gateway from the DHCP scope would eliminate the router as the next hop, breaking all off-subnet communication. The problem is isolated to hostname resolution while IP connectivity succeeds, so a missing gateway would cause total network failure, not just DNS failure. Therefore, the default gateway must remain in the scope and cannot be the cause.

The clients must use PPP before DNS works.

Why wrong: PPP (Point-to-Point Protocol) is a WAN data-link encapsulation used on serial or DSL links, not a service required for DNS on an Ethernet LAN. DNS resolution operates over IP and is independent of the data-link protocol; clients do not need PPP to send DNS queries. This option incorrectly conflates a WAN technology with local DHCP operation and is unrelated to the VLAN 70 issue.

The VLAN must be converted to the native VLAN on all trunks.

Why wrong: The native VLAN in 802.1Q trunks carries untagged frames; changing VLAN 70 to native would affect trunk tagging and could cause broadcast or misdelivery issues. However, the symptom is specifically that clients reach services by IP but not by hostname, indicating a DNS problem, not a Layer 2 forwarding issue. If the native VLAN were misconfigured, general connectivity would fail, not just name resolution.

The static route for 10.10.20.0/24 is missing from the routing table.

Why wrong: The routing table entry for 10.10.20.0/24 is visible in the output, showing 'via 10.10.10.2', so the static route is certainly not missing. This option misreads the table; the missing entry is actually the default route (0.0.0.0/0), not the static route to the 10.10.20.0 network. The presence of this specific static route does not affect the default route's reachability, which is the real issue.

The GigabitEthernet0/0 interface is administratively down.

Why wrong: The interface status in the exhibit is 'up/up' with IP address 10.10.10.1, and the connected route for 10.10.10.0/24 is present in the routing table. An administratively down interface would be 'shutdown' and would remove all connected routes, including the subnet that contains the next-hop. Since the next-hop is unreachable despite the interface being up, the problem lies with the remote router or Layer 2 connectivity, not the local interface state.

The default route is not configured; the gateway of last resort is missing.

Why wrong: The output includes the line 'Gateway of last resort is 10.10.10.2 to network 0.0.0.0', proving that a default route is configured and the router recognizes it as the gateway of last resort. However, the default route does not appear as an 'S*' entry in the routing table because the next-hop is unreachable. This option incorrectly assumes that the configuration is missing; in reality, the route is configured but not installed.

Change the AP from Ethernet to PPP encapsulation.

Why wrong: PPP (Point-to-Point Protocol) is a WAN encapsulation used on serial or dial-up links, not on Ethernet LAN segments where access points typically connect. Changing the AP's encapsulation to PPP would not affect CAPWAP, which runs over UDP/IP and expects Ethernet framing on the local LAN. The exhibit gives no indication of a serial link or PPP requirement, so this action is unrelated to the AP's inability to join the controller.

Remove the AP IP address so it can obtain an IP address automatically via DHCP.

Why wrong: Removing the static IP and switching to DHCP does not address the root cause because the problem is a layer 3 reachability misconfiguration, not the method of address assignment. If the DHCP scope also provides the same incorrect default gateway, the AP will obtain a valid address but still be unable to reach the controller. Even a dynamically assigned address requires a correct gateway to forward CAPWAP traffic; the static IP itself is not preventing the AP from joining.

Disable DHCP on the controller for all APs.

Why wrong: Disabling DHCP on the controller globally is incorrect because the exhibit indicates that the problem is specific to this AP's default gateway, and other APs are already joining successfully. Such a global change would disrupt DHCP-based provisioning for all access points, including the healthy ones, without correcting the faulty gateway on the problematic AP. The issue lies in the AP's local IP routing configuration, not in the controller's DHCP service.

Because OSPF always overrides static routing, regardless of prefix length.

Why wrong: The premise that OSPF automatically overrides static routing is false; routing decisions prioritize longest prefix match first, and only when prefix lengths are equal does administrative distance break the tie. A static route has an administrative distance of 1, which is far lower than OSPF's 110, so a static /24 would be preferred for that prefix. The real reason the OSPF route wins here is that the /26 route has a longer prefix length than the static /24, not because of the protocol type.

Because the static route must have an administrative distance of 255 to be considered.

Why wrong: The static route does not need to have an administrative distance of 255 to be considered; in fact, an AD of 255 is treated as unreachable and would not be installed in the routing table. The static route is indeed valid and present, but its /24 prefix is less specific than the OSPF /26 route. Cisco IOS selects routes based on the longest prefix match first, so the more specific /26 route wins regardless of the static route's administrative distance.

Because the destination 198.51.100.70 is outside both listed routes.

Why wrong: The destination 198.51.100.70 is not outside both routes—it lies within the static /24 range of 198.51.100.0 through 198.51.100.255 and also within the OSPF /26 range of 198.51.100.64 through 198.51.100.127. Since .70 is between .64 and .127, it is covered by the more specific OSPF route. Therefore, the claim that it is outside either network is incorrect.

172.16.0.0/16

Why wrong: Although 172.16.20.200 is within the 172.16.0.0/16 address block, this route has a prefix length of only 16 bits. The router selects the route with the longest matching prefix; since the routing table contains more specific routes (172.16.20.0/24 and 172.16.20.128/25), the /16 route is not considered for forwarding. It would only be used if no longer prefix matches existed. Its broad summary covers many subnets, but that generality disqualifies it in favor of the more exact /25 entry.

172.16.20.0/24

Why wrong: While 172.16.20.0/24 does encompass the destination IP address 172.16.20.200, it is not the route selected. Routers utilise the Longest Prefix Match rule, which dictates that the most specific route available in the routing table for a given destination IP address will be chosen. In this scenario, 172.16.20.128/25 is a more precise match. This option would be correct if the 172.16.20.128/25 route were absent, as it would then represent the longest prefix match.

The default route

Why wrong: A default route, typically 0.0.0.0/0, matches every destination IP address. However, it has the shortest possible prefix length (0), making it the least specific route. The longest prefix match algorithm always prefers the route with the greatest number of matching bits; here, both 172.16.20.0/24 and 172.16.20.128/25 match the destination with longer prefixes, so the default route is never selected for this packet. It serves only as a last resort when no other route matches the destination network.

Standard ACLs should be placed as close to the source as possible.

Why wrong: Placing a standard ACL close to the source is incorrect because it will evaluate every packet from that source regardless of its final destination, potentially dropping traffic that should be allowed to other networks. Since standard ACLs cannot match the destination address, a permit or deny statement applies globally to all destinations for the specified source. Cisco recommends applying standard ACLs near the destination, while extended ACLs — which can match destination — should indeed be placed close to the source to reduce unnecessary transit traffic.

Standard ACLs can filter traffic based on destination IP address.

Why wrong: Standard ACLs do not look at the destination IP address at all — each ACE contains only a permit/deny decision based on the source address, with an optional wildcard mask. Because the router never inspects the destination field of the packet, a standard ACL cannot differentiate between traffic going to one host and traffic going to another. This is why extended ACLs are required when you need to match both source and destination addresses.

Standard ACLs can filter traffic based on TCP or UDP port numbers.

Why wrong: Standard ACLs cannot filter by TCP or UDP port numbers because they operate only at Layer 3 and match solely on the source IP address and wildcard mask. Port fields are Layer 4 information, which the standard ACL code never examines; only an extended ACL (numbered 100–199 or named) can specify protocol and port numbers in its entries. Thus, any attempt to use a standard ACL to block a specific web service or application port will fail.

The static route overrides OSPF immediately because static routes always win.

Why wrong: Static routes do not 'always win' because route selection is based on administrative distance, not on the route type alone. By default, a static route has an AD of 1, which normally beats OSPF's 110, but here the static route's AD has been configured higher than OSPF's, allowing OSPF to remain preferred. Therefore, it is the specific numeric AD values that determine preference, not a blanket rule that static outranks dynamic routing.

Both routes must be installed simultaneously because they point to the same destination.

Why wrong: The router does not install both routes just because they point to the same destination; it installs only the one with the best (lowest) administrative distance for that prefix. Both routes would be installed only if they had equal AD and formed equal-cost multipath (ECMP), or if they addressed different prefixes. Since the same destination and differing ADs mean only OSPF is selected, simultaneous installation is not required.

The router removes the OSPF route because the static route has a manually configured distance.

Why wrong: A manually configured distance does not cause the router to remove the OSPF route. The router selects the route with the lowest AD for the destination; because the static route's manually configured distance is higher than OSPF's 110, OSPF remains the best route and stays in the routing table. The static route is simply not installed, and OSPF is not removed merely because a static route with a higher distance exists.

Set the interface network type to point-to-point

Why wrong: Setting the OSPF network type to point-to-point on the interface changes timer values and eliminates DR/BDR election, but Hellos are still sent periodically and the interface remains fully active in the OSPF process. Since the requirement is to prevent Hello transmission while still advertising the connected network, this does not satisfy it. The point-to-point type is appropriate for serial links but does not suppress adjacency formation.

Apply distribute-list out on the interface

Why wrong: A distribute-list out is used to filter routes from being advertised in routing updates, but OSPF does not use it to suppress Hellos; OSPF relies on the Hello protocol for neighbor discovery. This command operates on the routing table and redistributed routes, not on interface-level OSPF processes like Hello transmission. Thus, applying a distribute-list out on the interface has no bearing on whether the interface sends or receives Hellos.

The OSPF route is installed because cost 20 is lower than metric 0

Why wrong: This statement incorrectly compares OSPF's cost (20) to the static route's metric (0) and assumes a lower number wins. In Cisco IOS, a router first compares administrative distance when multiple routing sources provide a path to the same network; only if AD values are equal are metrics compared. Since the static route's AD of 5 is much lower than OSPF's default AD of 110, the static route is installed into the routing table despite OSPF having a lower metric value. The OSPF cost is irrelevant until the static route is removed, at which point OSPF becomes the active route by default, not because its cost is lower.

Both routes are installed as equal-cost paths automatically

Why wrong: Equal-cost multipath (ECMP) only applies when multiple routes to the same prefix have the same administrative distance and the same metric, and they are usually from the same routing protocol. Here the static route has an AD of 5 while OSPF has an AD of 110, so they are not equal from the router's perspective. Moreover, their metrics—0 for the static and 20 for OSPF—are not comparable across different protocols. Therefore, the router does not install both; it selects only the static route as the single best path.

The interface received a superior BPDU and became the root port.

Why wrong: STP role changes like becoming a root port occur when a superior BPDU is received, but that event would be reflected in spanning-tree state transitions and forwarding behavior, not in a security intrusion log. A hub does not originate BPDUs, and the error message clearly identifies a port-security violation rather than an STP topology change. Therefore, the interface's down state is due to security enforcement, not a spanning-tree decision.

The hub forced the interface to become a routed port.

Why wrong: A hub is a Layer 1 device that simply forwards electrical signals, so it cannot change the logical mode of a switch interface. A routed port is created only by explicitly removing Layer 2 switching with the "no switchport" command, which is not shown here. The log message references a port-security violation, not a change in interface mode.

DHCP snooping always shuts a port when a hub is attached.

Why wrong: DHCP snooping filters DHCP messages based on whether a port is trusted or untrusted; it does not count MAC addresses or react to the simple attachment of a hub. A hub only extends the collision domain, and it does not generate DHCP traffic or cause a DHCP snooping violation by itself. The exhibit shows a port-security restriction on secure MAC addresses, not any DHCP-related action.

The path with the higher OSPF metric

Why wrong: Selecting the path with the higher OSPF metric would contradict OSPF's SPF calculation, which always chooses the least-cost path to a destination. A higher cost indicates a less desirable route, such as one traversing slower or more numerous links, and OSPF will never prefer it over a lower-cost alternative for the same prefix. The only time a higher-metric path is used is if the lower-metric path is absent from the routing table.

Both paths equally, because the administrative distance is the same

Why wrong: Administrative distance is a Cisco-specific trust rating assigned to the routing protocol as a whole, not a per-path metric for selecting among OSPF routes. When two OSPF paths to the same prefix have unequal metrics, the router compares the OSPF cost values directly, and the lower-cost path wins. Equal AD only means both routes are equally trusted as OSPF-learned; it does not enable load balancing, which would require the OSPF metrics to be exactly equal.

Neither path, because two OSPF routes to the same prefix are invalid

Why wrong: OSPF is fully capable of learning the same prefix through multiple paths, as occurs in redundant OSPF networks where the SPF algorithm evaluates all available routes. Having two OSPF routes to 10.10.10.0/24 is not invalid; rather, OSPF processes them and selects the one with the lowest metric for installation in the routing table, while potentially keeping equal-cost paths for ECMP. Discarding both routes would leave the network without a route, which OSPF would never do if any path exists.

A NAT rule translating IPv6 to IPv4

Why wrong: IPv6 was designed to restore end-to-end connectivity without relying on NAT; in normal native IPv6 environments, routing uses global unicast addresses directly. A NAT rule that translates IPv6 to IPv4 would be an unnecessary and complex workaround, and it would not help the host reach off-link IPv6 destinations unless that IPv4 path itself is routed. Since the host already reaches neighbors using IPv6, the missing element is not address translation but a route to a default gateway.

A VLAN trunk on the host NIC

Why wrong: VLAN trunking is a Layer 2 feature used to carry multiple VLANs over a single switch link, typically between switches or to a router-on-a-stick. An end host NIC rarely requires trunking, and the symptom described is unrelated to VLAN tagging because it concerns Layer 3 reachability. Even if the NIC were configured with a trunk, that would not provide a default route or next hop for off-link IPv6 packets.

A second global unicast address on the same interface

Why wrong: Adding a second global unicast address to the same interface only provides an additional source or destination identifier for that interface; it does not install any route or gateway information into the host's IPv6 routing table. The host still lacks a default route for off-link traffic, and the existing address already satisfies the requirement of having a valid IPv6 source address. Therefore, a duplicate address does not solve the described reachability problem.

ifconfig

Why wrong: ifconfig is a legacy Unix tool for configuring and displaying network interfaces; it may be absent on modern Linux distributions that rely on iproute2. It shows local address and link status, but it never sends packets to a remote destination. Deprecated and often not installed by default, its interface display role is now superseded by 'ip addr'.

tracert

Why wrong: tracert is a Windows command that traces the path to a destination by sending ICMP packets with incrementally increasing TTL values and reporting intermediate routers. Linux uses 'traceroute' instead, typically with UDP or ICMP; the name and default behavior differ. It diagnoses routing paths, not basic connectivity, and may still show replies even if the final host rejects/doesn't respond to pings.

nslookup

Why wrong: nslookup queries DNS servers to resolve domain names to IP addresses or to retrieve DNS records like A, AAAA, MX, or NS. It tests the DNS resolution service, not IP connectivity; a successful query only proves the DNS server is reachable, not the target host. It is the wrong tool for checking whether a host is up, since it does not send any packets to the target host's IP address.