Which Command Should the Administrator Use Practice Questions

SW2 has a lower priority than SW1, so it takes longer to become the root bridge after failure.

Why it fails: Incorrect because the root bridge election is decided by bridge priority, but the priority value has no effect on convergence timing. Rapid PVST+ uses RSTP's proposal/agreement mechanism to rapidly transition ports to forwarding, and this occurs in milliseconds regardless of which switch is elected root. A lower priority on SW2 would only make it more likely to be root under normal operation; it would never cause it to 'take longer' to become root after a failure, since convergence speed is determined by protocol state machines and timers, not by priority.

BPDU Guard is enabled on the uplink ports, which prevents BPDU exchange.

Why it fails: Incorrect because BPDU Guard is a PortFast security feature that error-disables a port the moment it receives any BPDU, to prevent unauthorized switches from participating in spanning tree. It does not filter, drop, or slow BPDU exchange while the link is up; rather, it shuts the port down completely, which would cause an immediate loss of connectivity, not a delay in convergence. On normal uplink ports BPDU Guard is not enabled, and even if it were, it would not alter the STP timers or slow down the root port failover process.

Loop Guard is enabled on the uplink ports, which delays port transition.

Why it fails: Incorrect because Loop Guard is designed to protect against unidirectional link failures by blocking a port that stops receiving BPDUs, placing it in a loop-inconsistent state. It does not add any artificial delay to the normal forwarding transition process; instead, it actively prevents a port from becoming designated when BPDUs are absent, which is a safety measure, not a timer-based delay. Loop Guard would only interfere after a BPDU loss and would block the port entirely, so it cannot explain the slower convergence caused by using legacy STP timers.

The engineer used 'ip default-network' which is not supported in EIGRP; instead, 'default-information originate' should be used.

Why it fails: Ly states that 'default-information originate' should be used for EIGRP. That command is for OSPF, not EIGRP. While 'ip default-network' is indeed not supported in EIGRP, the correct method is to redistribute a properly configured static default route, not to use 'default-information originate'. Therefore, this is not the most likely reason.

The internal routers have a route to the default network with a better metric from another source.

Why it fails: Internal routers are not receiving the default route at all, so they cannot have a route with a better metric from another source. This option describes a scenario where the route is received but not preferred, which does not match the problem.

The engineer needs to configure 'eigrp stub' on the router to allow default route advertisement.

Why it fails: Configuring 'eigrp stub' on the router would restrict route advertisement, not allow it. To advertise a default route from a stub router, you would need the 'summary' keyword, but the router is not necessarily a stub. This would not be the most likely reason for the failure.

The IP SLA DNS probe must be configured with a 'timeout' value lower than 50 ms to detect the failure.

Why it fails: The statement suggests setting a timeout lower than 50 ms to detect failure, but that would only cause false failures because the RTT is exactly 50 ms for a valid cached response. The real problem is not that the probe is too slow; it is that the probe is answered from the router's cache, so it never touches the network. Lowering the timeout below the observed RTT would make the probe time out even when the server is healthy, which is not a legitimate detection of the server's actual reachability. The timeout parameter determines how long the router waits for a reply; it cannot force the probe to bypass the local DNS cache.

The DNS server is responding to the probe but not to other queries because the probe uses a different port.

Why it fails: This claim is incorrect because IP SLA DNS probes and standard DNS queries both use the same default destination port, UDP 53. The server does not treat traffic from an IP SLA probe differently based on source port, and the probe uses the identical DNS packet format as a normal query. If the server were reachable and responding to the probe, it would also respond to any other DNS query sent to the same destination IP and port. The reason the probe succeeds while other queries fail is that the probe's response is generated locally by the router's cache, not by the server.

The IP SLA operation is configured with a 'frequency' that is too low, causing the probe to be sent before the server times out.

Why it fails: The frequency parameter in IP SLA controls the interval between successive probes, not the behavior of any individual probe. A low frequency (e.g., a long interval) means probes are sent less often, but each probe still goes out and waits for a response according to its configured timeout. The server does not need to be "ready" at a certain time; it either answers or it does not. Since the probe in question is receiving a cached response, the frequency setting is irrelevant—changing it will not cause the probe to actually reach the DNS server or expose the server's unavailability.

The WLC is configured with the wrong authentication port; RADIUS uses port 1645, not 1812.

Why it fails: This is incorrect because RADIUS authentication uses UDP port 1812 as the IANA-assigned standard port; port 1645 is a legacy alternative from early RADIUS implementations that has been deprecated due to conflicts with the datametrics service. More importantly, the server logs in the scenario show that the WLC's Access-Request messages are being received, which proves the WLC is sending to the correct destination port (1812). If the WLC were mistakenly configured for 1645, the requests would never reach the RADIUS listener on 1812, and no Access-Reject entries would appear in the server logs.

The WLC's RADIUS server configuration has the wrong shared secret, causing the server to reject requests.

Why it fails: Incorrect because the server logs show 'Access-Reject', which indicates the server received the request and processed it; a shared secret mismatch would typically result in no response or a 'Access-Challenge' but not necessarily a reject. However, the server could still reject if the secret is wrong, but the WLC would still see a response, not 'server not responding'.

The WLC is not configured with a valid management interface IP address to reach the RADIUS server.

Why it fails: This is incorrect because the RADIUS server logs show that it is receiving Access-Request packets from the WLC, which proves the WLC's management interface has a valid IP address and can route to the server. An invalid management interface IP (or missing route) would prevent the WLC from sourcing or sending any RADIUS traffic, so the server would see nothing at all. The real issue is asymmetric routing or a source-address mismatch: the server replies from a different IP than the configured RADIUS server address, causing the WLC to drop those responses and log 'server not responding'.

The IP SLA operation must be configured with a 'request-data-size' value to match the remote router's MTU.

Why it fails: The request-data-size parameter for a UDP jitter operation only controls the payload size of the probe packets; it is optional and does not affect whether the remote router answers. The IP SLA responder on the destination processes jitter probes regardless of the configured data size, so this setting has no bearing on the failure. An MTU mismatch is a separate forwarding issue and is not relevant to the absence of a responder.

The source router needs a 'frequency' setting that matches the remote router's response interval.

Why it fails: The frequency command on the source router determines how often the IP SLA operation sends a new probe iteration; it is purely a local scheduling knob and has no corresponding value that must be matched on the remote router. The responder does not maintain its own 'response interval' that needs to align with that frequency, and jitter calculation is unaffected by this scheduling parameter. Changing frequency only changes the sample interval, not whether the remote responder generates a response.

The firewall on the remote router is blocking the UDP port 16384, preventing the probe from reaching the target.

Why it fails: A firewall blocking UDP 16384 could prevent a jitter probe from arriving, but that is a secondary issue and not the root cause described by the need for a responder. Even if the firewall permitted the probe, the remote router would still need an IP SLA responder to listen on that port and generate the return traffic; otherwise the packet is simply discarded. Moreover, the presence of a firewall does not explain why the operation can never establish with the responder, because the responder is mandatory regardless of firewall state.

The destination session on the central switch is configured with 'monitor session 2 destination remote vlan 999' instead of 'monitor session 2 destination interface Gi1/0/1'.

Why it fails: The destination session on the RSPAN destination switch should use 'monitor session 2 source remote vlan 999' to receive mirrored frames from the RSPAN VLAN, combined with 'monitor session 2 destination interface Gi1/0/1' to send those frames to the local analyzer port. The command 'monitor session 2 destination remote vlan 999' shown in the option is actually the syntax used on the source switch to direct mirrored traffic into the RSPAN VLAN, not on the destination switch. Since the question explicitly states that the destination session is configured, this misconfiguration cannot be the missing piece; the failure must lie in the Layer 2 path between the switches.

The source sessions on the remote switches are configured with 'monitor session 1 source vlan 100' but the destination is not set to 'remote vlan 999'.

Why it fails: A valid RSPAN source session must include both a monitored source and an output destination of 'remote vlan 999' — for example, 'monitor session 1 source vlan 100' followed by 'monitor session 1 destination remote vlan 999'. Without the destination remote clause, the session would not inject mirrored frames into the RSPAN VLAN and would instead behave as a local SPAN session. However, the question states that the source sessions are already configured, implying they have the required destination remote configuration. Therefore, the missing piece is not an incomplete source session but rather the trunk allowed list on the link connecting the source switches to the central switch.

The RSPAN VLAN is not created as a remote SPAN VLAN; it must be configured with 'remote-span' command.

Why it fails: Incorrect; the 'remote-span' command is used on the VLAN to designate it as an RSPAN VLAN, but the question says the VLAN is active, implying it is configured. However, this is a common missing step, but the most likely missing configuration is the trunk allowance.

The AS-path contains the local AS number.

Why it fails: This is incorrect. While an AS-path containing the local AS number can cause routes to be rejected due to loop prevention, the typical symptom is routes not being received at all or being marked as invalid, not the specific 'received but not valid' status. The most common cause for 'not valid' is next-hop unreachability.

BGP synchronization is enabled.

Why it fails: This is incorrect. BGP synchronization is a legacy feature that requires the route to be in the IGP before it is advertised. In modern networks, synchronization is disabled by default. Even if enabled, it affects advertisement, not the validity of received routes in the BGP table.

The maximum-prefix limit has been exceeded.

Why it fails: This is incorrect. Exceeding the maximum-prefix limit typically causes the BGP session to reset or routes to be withdrawn, not to be marked as 'not valid' in the BGP table. Routes would likely be removed entirely, not just marked invalid.

The router's interface is configured with the no ip forward-protocol udp bootps command.

Why it fails: The `no ip forward-protocol udp bootps` command disables the forwarding of UDP broadcasts destined for BOOTPS/DHCP port 67 by the relay agent. However, the router here is acting as the DHCP server itself, not as a relay. A local DHCP server receives DHCPDISCOVER broadcasts natively on its directly connected interface, so this command has no effect on the server's ability to see those broadcasts. This option is incorrect because it targets the relay function rather than the local server reception.

The DHCP pool is configured with the wrong default-router option.

Why it fails: The `default-router` option in a DHCP pool sets the gateway address that the client will configure via the DHCPOFFER message. This option does not influence whether the router receives the DHCPDISCOVER or whether the server responds to it. A wrong default-router address would cause the client to have an incorrect gateway after obtaining an address, but it would not prevent the client from being assigned an IP. Therefore, this cannot explain a complete failure to receive broadcast messages.

The router's DHCP server is disabled globally with the no service dhcp command.

Why it fails: The global `no service dhcp` command disables both the DHCP server and relay functionality on the router. If this were the cause, the router would not respond to any DHCP requests, but when an engineer attempts to configure a DHCP pool, Cisco IOS displays an error like 'DHCP is disabled on this router' or requires the `service dhcp` command to be enabled. Since the pool is presumably configured and active, the service must be running, making this option unlikely. This option is incorrect because the failure mode would be immediately apparent during configuration, not a silent absence of DHCPDISCOVER reception.

The switch must have 'aaa authentication dot1x default group radius' configured globally.

Why it fails: This global configuration is already assumed to be in place in the scenario, as the switch is attempting 802.1X authentication and the failure occurs at the interface level. The command 'aaa authentication dot1x default group radius' only specifies the authentication method and server; it has no role in assigning a VLAN to a failed or unauthenticated host. The missing piece is the interface-specific guest VLAN definition, not a global authentication rule.

The 'authentication host-mode multi-host' command should be replaced with 'authentication host-mode multi-domain' to support guest VLAN.

Why it fails: Replacing 'multi-host' with 'multi-domain' would change how multiple devices are authenticated on the port, but it does not affect whether a guest VLAN can be used. 'Multi-domain' restricts the port to one voice and one data device, while 'multi-host' allows any number of devices after a single successful authentication. Both host modes support a guest VLAN; the actual problem is that no guest VLAN has been configured with the 'authentication guest-vlan' command.

The port must be configured as a trunk port to allow the guest VLAN.

Why it fails: The guest VLAN is a single, untagged VLAN that the switch dynamically assigns to an access port when authentication fails; it is not a trunk VLAN. Trunk ports are designed to carry multiple VLANs with tagging, which would introduce unnecessary complexity and security risk for a guest access environment. A standard access port with 'authentication guest-vlan' is sufficient, and the command works regardless of the port's trunk or access mode—but using trunk would not solve the missing VLAN definition.

The physical interface is configured with 'no ip address'.

Why it fails: The physical interface in a PPPoE configuration is intentionally left without an IP address. This interface operates at Layer 2 only and is used to encapsulate PPPoE frames via a dialer pool, while the dialer interface carries all Layer 3 addressing. IPCP assigns the IP address to the dialer interface, not to the physical Ethernet port. Therefore, seeing 'no ip address' on the physical interface is both expected and correct, and it is not the cause of the connectivity failure.

The default route is pointing to the wrong next-hop IP.

Why it fails: A default route in a PPPoE environment is typically configured with the dialer interface as the egress, using the form 'ip route 0.0.0.0 0.0.0.0 dialer 0' rather than a concrete next-hop IP. If the default route points to a specific next-hop IP, that IP would normally be the ISP gateway IP assigned during IPCP. However, because the dialer interface lacks an IP address, IPCP has not provided that next-hop value, and even a correctly pointed route cannot function. Thus the issue is not the route's target, but the missing IPCP address that makes any route unusable.

The ISP's gateway is not responding to ICMP.

Why it fails: While an unresponsive gateway could cause symptoms like this, it is not the root cause when the PPPoE session is already up. A PPPoE session being established confirms that the Ethernet link, PPP authentication, and LCP negotiation have succeeded, but ICMP requires IP-level routing and addressing. If the dialer interface has no IP address, the router cannot generate an ICMP echo request, so the gateway's response (or lack thereof) is irrelevant. The gateway is not the problem; the router's own missing IP address prevents it from participating in IP communication.

Check the output of 'show vlan id 10' to see if VLAN 10 is active and mapped to the VNI.

Why it fails: The 'show vlan id 10' command displays VLAN information, such as ports and status, but it does not show VNI mapping or EVPN route advertisement. While VLAN-to-VNI mapping is necessary for VXLAN, this command does not verify EVPN control plane operations. The engineer should focus on EVPN-specific commands to troubleshoot route advertisement.

Check the output of 'show interface nve1' to verify that the NVE interface is operational.

Why it fails: The 'show interface nve1' command provides status and statistics for the NVE interface, such as whether it is up and the source IP address. However, it does not show EVPN route advertisement or VNI-to-EVPN association. While it is useful for verifying the NVE interface state, it does not address the specific issue of EVPN route advertisement for a VNI.

Check the output of 'show nve vni' to see if the VNI is up and associated with the NVE interface.

Why it fails: The 'show nve vni' command displays the status of VNIs and their mapping to VLANs, but it does not directly show EVPN route advertisement. While it can confirm that the VNI is up, it does not verify the EVPN control plane association. The engineer needs to check EVPN route advertisement specifically, so this command alone is insufficient.

Change the video traffic marking to DSCP AF41 and rely on DSCP-to-queue mapping

Why it fails: This is incorrect because, by default, Catalyst switches perform queue selection based on the CoS field, not the DSCP value, unless you explicitly configure 'mls qos trust dscp' and a DSCP-to-queue map (e.g., 'mls qos srr-queue output dscp-map'). Simply re-marking video to AF41 does not change the CoS-to-queue assignment, so video would still be placed in the same queue as voice if both have the same CoS or if the DSCP mapping is not defined. Furthermore, even with DSCP trust enabled, the default DSCP map might still not separate AF41 from voice, so an additional mapping change would still be required.

Apply a service policy that uses a priority queue for voice only

Why it fails: Applying a service policy that designates a strict priority queue for voice only does not address the underlying queue mapping problem. The priority command only dictates the scheduling behavior of the queue that voice is placed in; it does not alter which hardware queue video is mapped to. Since video remains in its default queue (which may be the same as voice if the CoS-to-queue mapping is unchanged), the two traffic classes will continue to share the same buffer and scheduling treatment. The correct approach is to remap the CoS values so that voice and video are assigned to different queues, then optionally apply priority scheduling to the voice queue.

Increase the number of queues to eight

Why it fails: Increasing the number of output queues to eight is impossible on most Catalyst switching platforms because the number of egress queues per port is fixed by the hardware and typically ranges from two to four, with some ASICs supporting more but not via a software command. Even on platforms that support eight queues, the real issue is that voice and video are currently colliding in the same queue due to the existing CoS-to-queue mapping. Merely adding queues provides no benefit unless the mapping is changed to direct the traffic into the new queues. There is no CLI command to alter the hardware queue count, so this option is not a valid solution.

The RP is not configured as the DR on its segment.

Why it fails: The Designated Router (DR) on a segment is responsible only for sending PIM register messages on behalf of a directly connected source, not for selecting the tree used by other routers. The RP's DR status on its own segment has no bearing on whether last-hop routers use the SPT or the shared tree. In this scenario, the issue is purely a tree-switching delay, not any DR misconfiguration on the RP's link.

The multicast source is using a different group address.

Why it fails: If the source were sending to a different group address, the last-hop router wouldn't receive those packets at all—they'd be dropped because the router has no group state for that other group. The fact that traffic is flowing at all, albeit via the RP, proves the group address is correctly matched. This option incorrectly conflates the tree type with group addressing; the group address is consistent, and the actual problem is the absence of an SPT switchover.

The last-hop router has a higher metric to the source than to the RP.

Why it fails: The SPT switchover in PIM-SM is triggered by the first packet arriving at the last-hop router, or by the spt-threshold configuration—not by any comparison of unicast metrics to the source versus the RP. Even if the metric to the source is higher, PIM defaults to switching to the SPT anyway, and a higher metric would only delay the switch if a policy like spt-threshold were in place. Thus, a metric difference alone cannot explain why the traffic remains on the shared tree.

The IP SLA operation is not configured with a 'request-data-size' that matches the remote router's MTU, causing fragmentation and delay variations.

Why it fails: Configuring a 'request-data-size' that exceeds the path MTU between the source and destination would cause IP fragmentation, possibly increasing delay and jitter or causing packet drops, but it cannot produce a negative one-way delay value. One-way delay is calculated as receive timestamp minus send timestamp; fragmentation only adds transit time, so the result would remain positive (or the probe would fail). Thus, this misconfiguration explains performance degradation, not the reported negative delay.

The IP SLA operation is using a 'frequency' that is too high, causing the probes to overlap and corrupt the statistics.

Why it fails: Setting the IP SLA 'frequency' to a value shorter than the operation's actual execution time can cause probes to overlap or be skipped, which may corrupt the statistics or cause false timeouts. However, overlapping probes would affect packet timing, loss, and jitter metrics, not the sign of the computed one-way delay. A negative delay is a mathematically impossible result under normal timing and is specifically a symptom of clock desynchronization, not probe scheduling.

The remote router's IP SLA responder is not configured, so the source is using a different method to estimate delay.

Why it fails: If the remote router did not have an IP SLA responder configured, the UDP jitter operation would fail entirely because it relies on the responder to process and timestamp the probe packets and return control messages. There is no fallback 'different method' for estimating one-way delay; the operation would report an error or no data. Consequently, a missing responder could not yield a negative delay value, as the measurement would never complete.

The priority queue is not configured with a bandwidth statement.

Why it fails: This is incorrect because, in LLQ, the priority queue is always configured with a bandwidth statement via the `priority` command. A missing bandwidth statement would make the configuration invalid or cause the class to be treated as a normal class, not a priority queue. The drops in question are due to the implicit policer that is activated when the priority bandwidth is assigned, not because of a missing statement. Thus, the problem is traffic exceeding the configured bandwidth, not the absence of a bandwidth value.

The class-map is not matching voice traffic correctly.

Why it fails: This is not the cause. The scenario explicitly states that drops are occurring in the priority queue, which proves that voice traffic is being matched and placed into that queue. If the class-map were misconfigured, voice traffic would be classified into a different queue (such as the default class) and would not experience policer drops. The fact that the drops happen at the priority queue indicates the matching is working correctly; the issue lies in the policer's configured bandwidth threshold.

The router is using FIFO queuing instead of LLQ.

Why it fails: This is incorrect because LLQ is indeed in operation, as evidenced by the policer dropping excess traffic. FIFO queuing has no built-in policer; drops under FIFO occur only through tail drop when the interface buffer is full, not based on a configured bandwidth. The scenario describes drops specifically due to policing, which is a signature feature of LLQ's priority queue. Therefore, the queuing mechanism is correctly identified as LLQ, and the drops are not caused by using FIFO instead.