Infrastructure practice questions

The network statement uses an incorrect subnet mask.

Why wrong: When using a network statement in classic EIGRP, you specify a network and a wildcard mask, not a subnet mask — for example, 'network 10.10.10.0 0.0.0.255'. If an admin mistakenly types a subnet mask like 255.255.255.0, the wildcard is interpreted as '0.0.0.255'? Actually the IOS may reject it or treat it as an ACL wildcard, leading to the interface not being included in EIGRP. This could result in hellos not being sent on that segment, which prevents adjacency, but the question specifically lists 'incorrect subnet mask' as the wrong answer because the EIGRP network statement nomenclature deals with wildcard masks, not subnet masks. Even if the wildcard is wrong, it does not necessarily prevent adjacency on a directly connected interface if that interface's IP is still included by another network statement.

One router has a loopback interface that is not advertised.

Why wrong: A loopback interface that is not advertised via an EIGRP network statement has no bearing on forming a neighbor adjacency because adjacencies are established on the interfaces used to physically or logically connect peers, not on the loopback. EIGRP does not require every interface to be in the routing process; it only needs the interface traversed by the neighbor packets to be covered by a network statement. Loopbacks often act as the router ID or are injected for management purposes, but their absence from EIGRP does not break hellos or neighbor relationships with directly connected routers.

The hello and hold timers do not match.

Why wrong: EIGRP timers do not need to match for two routers to become adjacent, which is a key difference from OSPF. Each router independently sends hellos every 'hello-interval' and waits a 'hold-time' to declare a neighbor dead; the router receiving a hello learns the source's hello interval, but uses its own locally configured hold time as the timeout. If hold time is shorter than the remote hello interval, the neighbor will time out and flap, but mismatched timers alone will not prevent the initial adjacency from forming. The question correctly marks this as wrong because a mismatch alone is not a barrier to adjacency; it can cause instability only if the hold time is too short.

CoS 5, DSCP AF41

Why wrong: AF41 (Assured Forwarding 4.1) is an admission-controlled video marking, not a voice marking. Voice traffic requires the strict-priority forwarding behavior of EF (Expedited Forwarding) to guarantee low latency, low jitter, and minimal loss; AF41, by contrast, is a lower-priority class that can be dropped during congestion. Using CoS 5 with DSCP AF41 creates a mismatch where Layer 2 says high priority but Layer 3 treats the traffic as ordinary video, leading to suboptimal queuing and potential voice quality degradation.

CoS 5, DSCP CS3

Why wrong: CS3 (Class Selector 3) is a DiffServ marking used for lower-priority traffic such as signaling or multimedia conferencing, not for voice bearer traffic. In the standard QoS model, voice must be marked as EF (DSCP 46) to receive strict-priority treatment; CS3, with a lower numerical DSCP value, gets placed in a lower queue and is subject to congestion-related delays and drops. Combining CoS 5 with DSCP CS3 contradicts the intended high-priority voice classification and causes inconsistent behavior on devices that trust only one marking.

CoS 4, DSCP EF

Why wrong: CoS 4 is conventionally assigned to video conferencing traffic on Cisco switches, placing it in a lower-priority queue to prevent it from starving voice. Although DSCP EF is correct for voice at Layer 3, pairing it with CoS 4 creates a marking conflict: a switch that trusts only CoS will classify this traffic as video, not as strict-priority voice. This mismatch can lead to voice frames being queued with video and experiencing delay or jitter, so the proper pairing for voice is CoS 5 with DSCP EF, not CoS 4.

WPA3-PSK with AES

Why wrong: WPA3-PSK is not a valid term because WPA3-Personal replaces the pre-shared key mechanism with Simultaneous Authentication of Equals (SAE), which eliminates offline dictionary attacks by performing a shared-password authentication using a Dragonfly key exchange. Even though WPA3 provides AES-based encryption (GCMP-256), the authentication is not PSK, so labeling it as WPA3-PSK is incorrect. Additionally, WPA3 requires support from both the AP and clients, which may not be present in a mixed legacy environment.

WPA2-PSK with TKIP

Why wrong: WPA2-PSK with TKIP is not acceptable because TKIP (Temporal Key Integrity Protocol) uses the RC4 stream cipher and was designed as a stopgap for WEP vulnerabilities; it does not employ AES. While WPA2 permits TKIP for legacy interoperability, it lacks the cryptographic strength of AES-CCMP and is deprecated in modern networking standards. Therefore, this would contradict the requirement for AES encryption.

WEP with AES

Why wrong: WEP with AES is an invalid combination because Wired Equivalent Privacy (WEP) is a legacy, broken security protocol that relies on RC4 with static keys and cannot support AES. AES is implemented in the 802.11i amendment via CCMP/AES-GCMP, and is only available in WPA2/WPA3. Thus this option is not even a possible configuration and would provide trivial security.

The router ID is the same on both routers.

Why wrong: A duplicate OSPF router ID causes a router to reject neighbor discovery packets that carry its own router ID, preventing the neighbor relationship from forming or causing it to flap. The adjacency typically cannot move beyond INIT or DOWN, and the error would not manifest as a neighbor stuck specifically in EXSTART state. Because the symptom here is an adjacency stuck in EXSTART, an RID conflict is a different failure pattern and is not the cause.

The area ID is different.

Why wrong: An OSPF Hello packet carries the originating area ID; if the receiving interface belongs to a different area, the Hello is dropped as invalid and no neighbor adjacency ever forms. In this case, the routers would never progress past the INIT state or would remain in DOWN with the relevant 'area mismatch' debugs, rather than moving through 2WAY to EXSTART. A wrong area assignment therefore produces a much earlier failure in the OSPF neighbor state machine than the observed EXSTART hang.

The hello timer is set to 30 seconds on one router.

Why wrong: When hello intervals differ, each router rejects the other's Hello packets because the Hello interval field does not match the local configuration, so the neighbor flips between DOWN and INIT. The routers never achieve the 2WAY state or proceed to database synchronization, meaning they cannot get stuck in EXSTART as seen in the scenario. The router may also show 'event timer' or 'dead timer' mismatches, but any timer mismatch keeps the adjacency in the earliest stages, not in EXSTART.

switchport access vlan 100

Why wrong: The interface configuration command 'switchport access vlan 100' assigns an interface to access VLAN 100, but it does not create the VLAN itself. If VLAN 100 has not been created with the 'vlan 100' command, this command will fail because the VLAN must already exist in the switch's database. This command is used only after VLAN creation, to place a port into that VLAN, making it a post-creation assignment step, not a VLAN creation method.

vlan database

Why wrong: The legacy command 'vlan database' enters a special VLAN database mode used in older IOS versions, but it does not create any VLAN by itself. This mode required you to then type 'vlan 100' inside that mode, and it stored VLAN information separately in a vlan.dat file rather than in the running configuration. It is deprecated in modern Catalyst switches, and its use is unnecessary and non-standard for creating a new VLAN in current IOS, making it an incorrect answer.

interface vlan 100

Why wrong: The command 'interface vlan 100' creates a Switch Virtual Interface (SVI), which is a Layer 3 logical interface representing a VLAN. However, this command does not create the underlying L2 VLAN; VLAN 100 must already exist in the switch's VLAN database for the SVI to function properly. An SVI is used for routing between VLANs, and its creation without an existing VLAN would cause it to be inactive or unsupported, so it cannot be used to create a VLAN itself.

The interfaces must be on the same physical switch.

Why wrong: HSRP is intentionally designed for two separate physical switches to provide gateway redundancy, such as in an access-distribution or distribution-core topology. The protocol relies on Layer 2 multicast, which only requires a trunk or VLAN that spans both devices; the physical chassis is irrelevant. As long as the VLAN is allowed on the inter-switch link, the two interfaces can be on different switches and form an HSRP group. Requiring the same physical switch is therefore incorrect and would undermine the device-level redundancy HSRP is meant to provide.

The interfaces must be Layer 2 switchports.

Why wrong: HSRP operates at Layer 3 because it requires an interface with an IP address and the capability to route frames; a Layer 2 switchport is purely a frame-forwarding port with no IP configuration. On a multilayer switch, HSRP is enabled on an SVI (VLAN interface) or a routed port, both of which are Layer 3 constructs. A Layer 2 switchport simply forwards Ethernet frames to the local VLAN and cannot run the HSRP election or own a virtual IP. Therefore, this option is incorrect.

The interfaces must have the same IP address.

Why wrong: Each HSRP participant must have its own unique real IP address in the same subnet to source hello packets and identify itself during the election process. The shared virtual IP is a service address configured with the standby command, and it is not used as the source IP in hello messages—each router uses its real IP instead. If both interfaces were assigned the same IP, an address conflict would occur, breaking routing and ARP. Thus, the interfaces need different real IPs plus one common virtual IP.

The AS number is incorrect.

Why wrong: If the AS number were incorrect, the BGP neighbors would fail to establish a session because the OPEN message would contain a conflicting AS number, triggering a NOTIFICATION and transitioning to Idle/Active state. Since the session is already established and routes are being exchanged, an AS number mismatch is not the cause of the missing route. This condition specifically prevents peering, not route installation after peering is up.

The BGP session is using an incorrect interface.

Why wrong: Configuring the BGP session on the wrong interface would mean the TCP connection to the peer could never be established, as BGP would send packets from an interface that cannot reach the peer's IP address. The fact that the session is up proves the interface selection and underlying IP connectivity are correct. Therefore, an incorrect interface cannot be the reason a specific route is absent from the routing table.

The network is not advertised under BGP.

Why wrong: Not advertising a network under BGP only affects what the local router sends to its peers; it has no effect on the routes received from an established neighbor. If the network is missing from BGP updates, the problem would be on the advertising side, not on this router's inability to install a received route. Since the issue is about a route not being received or installed, this option does not explain the symptom.

switchport mode trunk

Why wrong: The 'switchport mode trunk' command unconditionally enables trunking, but it does not specify the encapsulation protocol. On older Catalyst switches that support both ISL and 802.1Q, the default encapsulation may be ISL, so this command alone does not directly configure 802.1Q trunking. To ensure 802.1Q, an explicit encapsulation command is required, making this option incomplete for the stated task.

switchport mode access

Why wrong: The 'switchport mode access' command forcibly disables trunking by setting the interface as an access port, which carries traffic for only a single VLAN and sends all frames untagged. This is the opposite of trunking and, therefore, cannot be used to configure 802.1Q trunking. Even if a remote switch is configured for trunk, an access port will not form a trunk link.

switchport trunk native vlan 1

Why wrong: The 'switchport trunk native vlan 1' command only designates VLAN 1 as the native VLAN for an existing trunk, and does not enable trunking itself. This command is applied after trunking is established, and it controls which VLAN is sent untagged on the trunk. Without first configuring trunk mode and encapsulation, this command has no effect on enabling 802.1Q trunking.

Matching authentication (if configured)

Why wrong: Authentication is optional in OSPF, so in a default configuration there is no authentication parameter to compare and adjacencies form without it. Only when authentication is explicitly enabled must the type (null, simple, cryptographic) and the password or key ID match, causing Hello packets to be discarded if a mismatch occurs. Since it is contingent on configuration, it is not a universal requirement for adjacency establishment.

Same subnet mask

Why wrong: The Hello protocol checks that the network number of the receiving interface matches the network number of the sending interface, but it does not compare subnet masks directly. Two routers can form an adjacency if their IP addresses belong to the same subnet even if the configured masks differ, because OSPF derives the network number from the address and mask. On point-to-point links, the mask is ignored entirely, further confirming that identical subnet masks are not a prerequisite.

Backup Designated Router

Why wrong: In OSPF's DR/BDR election process on a broadcast or non-broadcast multi-access network, a router with interface priority 0 is explicitly marked as ineligible to become either the Designated Router or the Backup Designated Router. Since the exhibit shows priority 0 for r1, it cannot fulfill the BDR role, making this option incorrect. The BDR role would only be possible if the priority were greater than 0 and r1 lost the DR election to a higher-priority router.

Regular router

Why wrong: The term 'regular router' is not a valid OSPF state or role in the neighbor state machine. OSPF defines specific states for routers on multi-access networks: DR, BDR, and DROther, along with neighbor states like Full and Two-Way. Calling r1 a 'regular router' is vague and incorrect because it does not correspond to any protocol-specific function. In the context of OSPF operation, r1's actual role is DROther.

Designated Router

Why wrong: The Designated Router (DR) election also uses the router priority value, and a priority of 0 disqualifies r1 from becoming the DR on this segment. Even if r1 has the highest router ID, its configured priority of 0 overrides that and prevents any chance of winning the election. Therefore, r1 cannot be the DR, and the exhibit's priority 0 setting directly contradicts this option.

The new switch is not configured with the same VLANs as the distribution switches.

Why wrong: A lack of identical VLAN configurations does not create loops; instead, it causes per-VLAN connectivity failures because traffic for missing VLANs is simply not forwarded. The switch can still run STP and maintain a loop-free topology for the VLANs it does carry. The described symptoms of broadcast storms and severe degradation are not consistent with a simple VLAN mismatch, which would affect only specific VLAN traffic.

The new switch has a lower bridge priority than the current root bridge.

Why wrong: Setting a lower bridge priority makes the new switch more eligible to become the root bridge, but STP still ensures a loop-free environment regardless of which switch is root. The root bridge is a legitimate role, and changing it merely alters the topology paths, causing some traffic to take different routes. It would not by itself generate the broadcast storms or MAC flapping indicative of a Layer 2 loop, so this is not the cause.

The new switch has become the root bridge and is sending inferior BPDUs.

Why wrong: The root bridge does not send inferior BPDUs; it sends superior BPDUs with a higher priority that other switches accept as the best. Becoming the root bridge is a normal condition and does not inherently create loops. This option is incorrect because it both mischaracterizes BPDU behavior and confuses a topology change with a loop, which is the actual cause.

The default route on the CE is overriding the BGP routes.

Why wrong: A default route (0.0.0.0/0) on the CE has the least specific prefix length, so it is used only for destinations that do not match a more specific route. BGP-advertised prefixes (e.g., /24s) are more specific and will always be preferred over the default route for matching traffic, regardless of the administrative distance. Thus, a default route cannot override or mask BGP routes; it simply provides a fallback when no specific route exists.

The routes have an AS path that is too long.

Why wrong: AS path length is a BGP best-path selection criterion, not a route-installation filter. BGP accepts and installs any valid route from a peer, even if its AS path is very long, as long as it passes basic validation (e.g., next-hop reachability). In practice, an AS path would have to exceed the 255-attribute segment limit to be considered invalid, which is extremely rare and not a typical reason for missing routes.

The CE is not advertising its routes to the PEs.

Why wrong: This explanation confuses outbound route advertisement with inbound route reception. The CE not advertising its own routes to the PEs would affect what the PE learns and can redistribute, but it does not prevent the CE from receiving BGP routes that the PE sends. The issue described is that the CE is not receiving/installing routes from the PE, which is a problem with the BGP session or the route attributes (like next-hop reachability), not with what the CE advertises.

It runs a single spanning-tree instance for all VLANs.

Why wrong: Rapid PVST+ does not run a single spanning-tree instance for all VLANs; that behavior describes MST (Multiple Spanning Tree) or the legacy Common Spanning Tree (CST). Instead, Rapid PVST+ creates a separate RSTP instance for every VLAN, allowing per-VLAN path optimization, per-VLAN root bridge selection, and independent port states for each VLAN's topology.

It eliminates the need for BPDUs.

Why wrong: Rapid PVST+ absolutely still requires BPDUs for loop prevention and topology discovery. It sends and receives 802.1w RSTP BPDUs on all ports, using flags for proposal/agreement, learning, forwarding, and topology change. Without BPDUs, switches could not exchange root information, detect loops, or converge; eliminating BPDUs would break spanning-tree operation entirely.

It supports PortFast to enable immediate transition to forwarding.

Why wrong: PortFast is an optional, per-port feature that can be manually enabled on edge ports to skip the listening and learning states and immediately transition to forwarding; it is not an inherent characteristic of Rapid PVST+ operation. The protocol itself still runs RSTP and brings up normal ports through the learning state. Saying Rapid PVST+ 'supports PortFast' is true, but that support is a configuration tool, not a default behavior or protocol mechanism, so it is not a characteristic of the protocol's operation.

One route has a higher administrative distance.

Why wrong: Administrative distance is a per-protocol preference value; all OSPF routes, including external types like E2, have the same AD of 110 on Cisco devices. For two routes to be considered equal-cost candidates for the same prefix, they must have identical AD and equal metric. A difference in AD would cause the route with the lower AD to be installed and the other ignored, not shown as an alternative. Therefore, the exhibited equal-cost routes cannot be differentiated by administrative distance.

A default route is overriding the specific route.

Why wrong: A default route is a prefix of 0.0.0.0/0 that is only used when no more specific prefix matches the destination IP. In the routing table, a specific route to the destination always wins over a default route regardless of metric or administrative distance due to longest-prefix-match. The exhibit clearly lists two routes to a specific network, not a default route; there is no default route shown, and even if one existed, it would not influence the selection between two specific routes. Hence, a default route is not overriding the specific route.

The route via 10.0.2.2 is an E1 route.

Why wrong: The routing table in the exhibit explicitly labels both entries as E2, indicating OSPF external type 2 routes. E1 and E2 differ fundamentally: E1 metric includes the internal cost from the router to the ASBR, while E2 metric is the ASBR-advertised external cost alone. If one route were E1, its metric would be larger by the internal cost and it would not share the same metric value for equal-cost load balancing. Since the label and the equal shown metric confirm both are E2, the route via 10.0.2.2 cannot be an E1 route.

Disable PortFast on all access ports to force proper RSTP convergence.

Why wrong: Disabling PortFast on access ports does not affect root port selection and would only slow down convergence for end devices; it does not solve the equal-cost path flapping.

Configure spanning-tree vlan 10 priority 4096 on DS1 to ensure it remains the root and that AS2 selects the uplink to DS1 as root port.

Why wrong: Lowering DS1's priority to 4096 is unnecessary because DS1 is already the root bridge (priority 32768 by default). This does not change the fact that both uplinks from AS2 have equal cost, so flapping continues.

Increase DS2's priority to 8192 to make it less likely to become the root.

Why wrong: Increasing DS2's priority to 8192 makes it even less likely to become root, but since it is not the root, this does not affect the equal-cost path selection from AS2; the tie remains.

Step 1: Exchange routing updates. Step 2: Send Hello packets. Step 3: Discover neighbors. Step 4: Maintain neighbor state.

Why wrong: Routing updates cannot be sent before an EIGRP adjacency exists. EIGRP relies on Hello packets to establish a neighbor relationship and determine initial parameters such as hold time and K-values. The reliable transport (RTP) used for updates requires an active neighbor entry with sequence numbers and a RTT calculated from the Hello exchange. Without the initial Hello/discovery phase, there is no neighbor to send updates to, so this ordering is fundamentally invalid.

Step 1: Discover neighbors. Step 2: Send Hello packets. Step 3: Exchange routing updates. Step 4: Maintain neighbor state.

Why wrong: Neighbor discovery in EIGRP is not an explicit step that can happen before any packets are sent—it is a consequence of receiving Hello packets. A router actively multicasts Hello packets to 224.0.0.10 on directly connected interfaces; a neighbor is 'discovered' only when a Hello is heard. Thus, placing 'Discover neighbors' before 'Send Hello packets' reverses the cause-and-effect relationship. The discovery event is the start of forming an adjacency, but it must be triggered by the Hello exchange itself.

Step 1: Send Hello packets. Step 2: Exchange routing updates. Step 3: Discover neighbors. Step 4: Maintain neighbor state.

Why wrong: This sequence incorrectly places routing updates before adjacency has been fully formed. After sending Hello packets, a router must receive Hello packets back and pass neighbor-matching checks (AS number, K-values, hold timer) before the neighbor is considered discovered and an adjacency is established. Only after that per-neighbor condition is met can routing updates be exchanged via multicast to 224.0.0.10. Prioritizing updates before discovery would require a valid route to a non-existent neighbor and is logically impossible in the neighbor state machine.

Configure the port as a dynamic desirable port.

Why wrong: Dynamic desirable is a DTP mode, not a trunk.

Configure the port as a routed port.

Why wrong: Routed ports are Layer 3 interfaces.

Configure the port as an access port.

Why wrong: Access ports carry only one VLAN.

Apply an extended ACL to the vty lines.

Why wrong: Extended ACLs are not necessary for source-only filtering.

Apply a named ACL to the interface.

Why wrong: ACL should be applied to vty lines, not interface.

Apply an ACL to the console line.

Why wrong: Console line does not require ACL for SSH.

Enable AAA authentication.

Why wrong: AAA is a broader framework.

Use the service password-encryption command.

Why wrong: Encrypts passwords but does not set enable password.

Configure login local on the console line.

Why wrong: This is for user authentication, not enable.

ICMP traffic from any source

Why wrong: ICMP is not permitted.

FTP traffic from 192.168.1.0/24

Why wrong: FTP is not permitted.

SSH traffic from 192.168.1.0/24

Why wrong: SSH is not permitted.