Network Assurance practice questions

Set both sides to access mode.

Why it fails: Setting both sides to access mode would place the ports in different VLANs, breaking the trunk link and causing connectivity loss.

Disable DTP on both sides using switchport nonegotiate.

Why it fails: Disabling DTP with 'switchport nonegotiate' on both sides while one side remains in 'dynamic desirable' would prevent trunk negotiation, leading to a mismatch unless both sides are manually set to trunk or access.

Change one side to dynamic auto.

Why it fails: Changing one side to 'dynamic auto' would put it in a passive listening state, while the other side is in 'dynamic desirable' (active), which should negotiate a trunk, but the intermittent issue indicates that DTP negotiation is still causing instability, so static trunk is preferred.

OSPF is load balancing across both paths equally.

Why it fails: OSPF performs equal-cost multipath (ECMP) only when the SPF metrics to the destination are exactly identical. Here the route via R2 has a cumulative cost of 20, while the route via R3 has a cost of 40, so the Dijkstra algorithm selects only the R2 path for the routing table. A difference in cost means no load balancing occurs, making this option incorrect.

The OSPF network type on R1-R3 is broadcast, causing DR/BDR election issues.

Why it fails: Setting the R1-R3 link network type to broadcast would trigger a DR/BDR election, but election success is a normal part of OSPF operation and does not by itself affect path selection. On a broadcast segment, DROther routers establish Full adjacencies with the DR/BDR, and all neighbors reported Full indicates the election completed without issue. Even if DR/BDR roles existed, the decision to use the R2 route is still driven by the SPF cost calculation for the destination, not by the network type. Therefore this option is incorrect.

The R1-R3 link is flapping, causing OSPF to prefer the stable path via R2.

Why it fails: A flapping R1-R3 link would prevent the OSPF neighbor adjacency from remaining in the Full state; instead, it would oscillate through Down/Init/ExStart/Exchange/Loading as hellos and database descriptors were dropped. The scenario explicitly states all adjacencies are Full, directly invalidating the flapping premise. Moreover, OSPF's SPF algorithm chooses routes based on metric, not stability, so a stable but higher-cost path would never become preferred unless its cost was manually lowered. This option cannot explain the observed preference.

Increase the bandwidth on GigabitEthernet0/0.

Why it fails: Increasing bandwidth on GigabitEthernet0/0 actually decreases the EIGRP composite metric because EIGRP calculates the bandwidth component as 10,000,000 divided by the minimum bandwidth along the path; a larger bandwidth value yields a smaller quotient. Since the question asks for a way to increase the metric for this route, this change has the opposite effect and would only make the route more preferred, not less.

Add a redistribute static command under EIGRP.

Why it fails: Adding a `redistribute static` command under EIGRP would inject static routes into EIGRP as external routes with an administrative distance of 170, but this action has no bearing on the existing route's EIGRP metric. The metric of a route is derived from the interface delay and bandwidth values at the time the route is learned or advertised; redistributing unrelated static routes does not alter those delay or bandwidth values, and the route in question remains unchanged.

Change the administrative distance to 90.

Why it fails: Changing the administrative distance to 90 does not alter EIGRP's composite metric, which is computed solely from bandwidth, delay, load, and reliability (using the configured k-values). Administrative distance is a separate trustworthiness value used only to choose between routes learned from different routing protocols, and it is never a component of the EIGRP metric formula; therefore the exhibited route's metric value stays identical, so the route selection behavior based on metric does not change.

802.11b: 5 GHz, 54 Mbps

Why it fails: Incorrect — 802.11b does not use 5 GHz; its max rate is 11 Mbps on 2.4 GHz.

802.11g: 2.4 GHz, 11 Mbps

Why it fails: Incorrect — 802.11g supports up to 54 Mbps, not 11 Mbps.

show interfaces GigabitEthernet1/0/1

Why it fails: This command displays detailed interface statistics, including duplex and speed, but it is not the most efficient for a quick check of duplex/speed status across multiple ports. It provides extensive output that may obscure the specific values. For a concise view, 'show interfaces status' is preferred. However, it does contain the information, so it is not entirely wrong, but less optimal.

show running-config interface GigabitEthernet1/0/1

Why it fails: This command shows the configuration of the interface, including any duplex and speed commands if manually set. However, if the interface is set to auto-negotiate, the running-config may not display the actual operational duplex and speed. Thus, it may not reveal the mismatch. The operational status is better seen with 'show interfaces status'.

show controllers ethernet-controller GigabitEthernet1/0/1

Why it fails: This command displays low-level controller information and statistics, such as register values and error counters. It does not directly show the configured duplex and speed settings. While it can help diagnose physical layer issues, it is not the appropriate command to verify duplex and speed configuration in this scenario.

IP SLA with ICMP Echo operation

Why it fails: IP SLA with ICMP Echo measures round-trip time and reachability to a destination but does not reveal the path or per-hop latency. It cannot show which routers the traffic traverses. Therefore, it does not fulfill the requirement to verify the actual path and hop-by-hop latency.

NetFlow with ingress and egress timestamps

Why it fails: NetFlow can provide traffic flow statistics and timing information, but it does not trace the path or show per-hop latency. It aggregates flow data and lacks the granular hop-by-hop view needed to verify the exact path and measure delay at each router.

Cisco IOS Embedded Packet Capture (EPC)

Why it fails: EPC captures packet contents at a specific interface, allowing detailed analysis of headers and payloads. However, it does not provide path information or latency measurements between hops. It is used for deep packet inspection, not for tracing the route or measuring per-hop delay.

Device 360 view for the access switch

Why it fails: Device 360 gives detailed information about a specific device, such as CPU, memory, and interface statistics. It does not directly provide application-level metrics like jitter and latency for voice traffic. While it can help identify device-level issues, it is not the primary tool for analyzing voice quality.

Path Trace tool

Why it fails: Path Trace is used to discover the path that traffic takes through the network and can identify ACLs or devices along the path. It does not provide latency or jitter measurements for voice traffic. It is useful for path analysis but not for performance metric analysis.

Network Health dashboard

Why it fails: The Network Health dashboard provides an overall health score for the network, including device and link health. While it can indicate that there is a problem, it does not provide the granular latency and jitter metrics needed for voice quality analysis. It is more of a high-level monitoring tool.

show controllers GigabitEthernet1/0/1

Why it fails: The show controllers command displays low-level hardware information about the interface, such as the ASIC and buffer details. It does not provide the duplex or speed configuration. While it can be useful for advanced troubleshooting, it is not the correct command to directly confirm a duplex mismatch in this scenario.

show interfaces status

Why it fails: The show interfaces status command displays the status, VLAN, duplex, speed, and type for all interfaces. It does show the duplex mode of the switch port, but it does not reveal the duplex setting on the connected server. A duplex mismatch requires comparing both ends; this command alone cannot confirm that the server is set to full-duplex while the switch port is half-duplex.

show interfaces counters errors

Why it fails: The show interfaces counters errors command displays error counters such as FCS, alignment, and late collisions. While late collisions are a classic symptom of a duplex mismatch, the command does not directly indicate the duplex configuration of either the switch port or the server. It provides indirect evidence but not the direct duplex settings needed to confirm the mismatch.

Configure a default static route and enable Policy-Based Routing (PBR) with a route map that matches the next-hop IP address.

Why it fails: PBR is used to forward traffic based on policy, not to conditionally install routes. A default static route would always be present, and PBR would not remove it if the next hop becomes unreachable. This approach does not provide automatic failover based on next-hop reachability.

Configure a static route with a lower administrative distance and enable Bidirectional Forwarding Detection (BFD) on the next-hop interface.

Why it fails: BFD can detect failures quickly, but it does not automatically remove a static route from the routing table unless it is tied to a tracking mechanism. A static route with a lower administrative distance would be preferred, but without tracking, it would remain even if the next hop fails. BFD alone does not provide the conditional installation required.

Configure a static route with the permanent keyword and enable IP SLA tracking to monitor the next-hop address.

Why it fails: The permanent keyword keeps the static route in the routing table even if the interface goes down, which is the opposite of what is needed. IP SLA tracking would not remove the route because the permanent keyword overrides the tracking status. This would not provide the desired failover behavior.

show ip sla application

Why it fails: This command provides information about the IP SLA application, such as supported operation types and maximum operations, but it does not show per-operation configuration. It is a general command and will not reveal the source interface or VRF for a specific probe, making it unsuitable for this troubleshooting task.

show ip sla statistics

Why it fails: This command shows the results and statistics of IP SLA operations, such as success and failure counts, but it does not display configuration details like the source interface or VRF. It is useful for monitoring performance but not for verifying the configuration parameters that determine how probes are sent.

show ip sla configuration

Why it fails: This command displays the configuration of all IP SLA operations, including type, frequency, and timeout, but it does not show the source interface or VRF. To see VRF information, you must use a more specific command. Therefore, this command alone will not provide the required details about the source interface and VRF binding.

Configure a tracking object that tracks the IP SLA operation and use 'track' with 'syslog' in the tracking configuration.

Why it fails: Tracking objects can monitor IP SLA operations and trigger actions, but there is no 'syslog' option within track configuration. Syslog messages are generated when the tracked object changes state if logging is enabled for the tracking object. However, the question asks for a syslog when the operation times out, which is a specific event.

Configure the IP SLA operation with the 'threshold' command and set the threshold type to 'timeout'.

Why it fails: The 'threshold' command is used to set rising and falling thresholds for performance metrics like RTT, not for timeouts. There is no threshold type 'timeout'. Timeouts are handled by the operation's timeout value, but syslog generation is not directly tied to thresholds.

Configure the IP SLA operation with the 'timeout' command and enable 'logging' under the operation.

Why it fails: The 'timeout' command sets the timeout value for the operation, but it does not generate syslog messages. Syslog messages are triggered by threshold violations or state changes, not by the timeout itself. Enabling logging under the operation is not a valid command; logging is configured globally or via tracking.

The flow record must be associated with a flow sampler to collect any data.

Why it fails: A flow sampler is optional and used for sampling packets, not for basic flow collection. Without a sampler, all packets are examined, which is actually the default behavior. The absence of a sampler would not cause zero flows; it would simply mean no sampling is applied, so this is not the cause.

The flow exporter was not configured and associated with the flow monitor.

Why it fails: A flow exporter is only required to export flow data to an external collector. The local cache should still populate with flow entries even without an exporter, so the absence of an exporter would not prevent the cache from showing data. This option is incorrect because the scenario does not mention exporting; the issue is with local flow data visibility.

The flow record does not include the 'match ipv4 protocol' field, which is mandatory for all flow records.

Why it fails: While matching the protocol is common, it is not mandatory for a flow record to function. Flexible NetFlow allows customization, and omitting a field does not prevent the record from collecting flows. The problem described is that no data appears at all, which is not caused by a missing optional match field.

ip sla 1 icmp-echo 10.1.1.1 frequency 60 timeout 5

Why it fails: This configuration sets the timeout to 5, which is interpreted as 5 milliseconds, not 5 seconds. The timeout command in IP SLA uses milliseconds. A 5-millisecond timeout is far too short and would cause the operation to time out almost immediately, leading to false positives for reachability issues. The correct value for 5 seconds is 5000 milliseconds.

ip sla 1 icmp-echo 10.1.1.1 interval 60 timeout 5

Why it fails: This configuration uses the interval command, which is not valid in IP SLA operation configuration mode. The correct command to set the frequency is frequency. Additionally, the timeout is set to 5 milliseconds instead of 5000 milliseconds. This configuration would fail or not behave as intended.

ip sla 1 icmp-echo 10.1.1.1 frequency 60 timeout 5 seconds

Why it fails: This configuration attempts to specify '5 seconds' as the timeout value, but the timeout command only accepts a numeric value in milliseconds. Adding 'seconds' is invalid syntax. The correct way to set a 5-second timeout is to use timeout 5000. This command would be rejected by the CLI.

snmp-server host 192.168.1.100 version 2c public

Why it fails: This command specifies the SNMP host (management server) to receive traps, along with the SNMP version and community string. It does not enable any traps by itself; it only defines the destination. Without enabling specific traps or all traps, no traps will be sent to this host. It is a necessary but insufficient step.

snmp-server community public RO

Why it fails: This command configures a read-only community string for SNMP polling. It does not enable traps; it only allows the management server to query the router. Traps are unsolicited notifications, and this command does not affect their generation. Therefore, it does not fulfill the requirement to send traps for all severities.

snmp-server ifindex persist

Why it fails: This command ensures that ifIndex values for interfaces are persistent across reboots, which is useful for consistent SNMP polling. It has no effect on enabling traps. It is unrelated to the requirement of sending traps for all severity levels. Thus, it is incorrect for this scenario.

Use the Client 360 view to see detailed information about the client's connection, including RSSI and SNR.

Why it fails: Client 360 is a powerful feature that provides detailed client metrics, but it is not an action to resolve the issue; it is a monitoring view. The question asks for actions to troubleshoot and resolve, and while Client 360 aids troubleshooting, it does not directly resolve the problem. The correct actions are those that actively diagnose and pinpoint the issue.

Configure a new SSID with the same VLAN to offload clients from the congested AP.

Why it fails: Creating a new SSID with the same VLAN does not offload clients; it adds another service set but does not change the radio or client distribution. Client load balancing is typically handled by the wireless controller's load balancing features, not by adding SSIDs. This action could increase overhead and does not directly address the performance issue.

Enable Cisco AI Network Analytics to automatically detect and resolve the issue without intervention.

Why it fails: Cisco AI Network Analytics provides insights and anomaly detection but does not automatically resolve issues without intervention. It can suggest remediation, but the administrator must apply changes. The question asks for actions that can be taken to troubleshoot and resolve, implying direct administrator actions, not automated resolution.

The switch is configured with a large number of static ARP entries, causing the ARP Input process to constantly refresh them.

Why it fails: Static ARP entries do not expire and do not cause the ARP Input process to run. The ARP Input process is responsible for processing incoming ARP packets, not maintaining static entries. A large number of static entries would consume memory but would not generate CPU load for the ARP Input process. Therefore, this is not a plausible cause.

The switch is the target of an ARP spoofing attack, causing it to process a large number of gratuitous ARP packets.

Why it fails: ARP spoofing involves forging ARP replies to associate a MAC address with multiple IPs. While this can cause ARP table churn, the ARP Input process specifically handles ARP packets destined to the switch's own IP addresses. Gratuitous ARP packets are broadcast and typically processed by the ARP Input process only if they are for the switch's IP. A spoofing attack would more likely affect the ARP table and cause other processes like ARP Background to spike, not necessarily ARP Input.

A malware infection on a host is sending a large number of ARP requests for non-existent IP addresses.

Why it fails: While ARP scanning by malware can cause high ARP Input CPU, it typically results in a high number of ARP requests, but the switch would process them relatively quickly. The ARP Input process handles ARP packets destined to the switch's own IP addresses, not transit ARP requests. Malware scanning usually targets a subnet, but the switch's CPU would be impacted if the ARP requests are directed to its management IP, which is less common. This is not the most likely cause.

Configure an IP SLA operation with the icmp-echo operation type and enable the ip sla responder on the target server.

Why it fails: The ip sla responder is used on the target device to respond to probes, but it is not required for icmp-echo operations because ICMP echo requests are handled natively by the target's IP stack. Enabling the responder does not generate syslog messages on the source router. Syslog generation requires a tracking object and logging traps, not a responder.

Configure an IP SLA operation with the icmp-echo operation type and enable the ip sla logging traps command.

Why it fails: The icmp-echo operation type monitors reachability, and ip sla logging traps enables syslog messages for IP SLA events, but this alone does not trigger a syslog when the server becomes unreachable. A tracking object must be configured and linked to the operation, and then the track state must be monitored to generate syslog messages. Without a track object, no syslog is sent for reachability changes.

Configure an IP SLA operation with the icmp-echo operation type and use the ip sla schedule command to start the operation immediately.

Why it fails: Scheduling the operation starts the monitoring, but it does not generate syslog messages on state changes. The ip sla schedule command only defines when the operation runs. To receive syslog alerts, a tracking object and logging traps are required. Without those, the operation runs silently and only statistics are available via show commands.

Configure a syslog server on DNA Center and create a syslog filter for interface down messages.

Why it fails: DNA Center can receive syslogs, but the Assurance feature for alerting on interface status is through health policies and notifications, not syslog filters. Syslog filtering is more manual and less integrated with the Assurance dashboard. This option does not leverage the built-in Assurance capabilities.

Enable IP SLA on the switch and configure DNA Center to poll the IP SLA results for interface status.

Why it fails: IP SLA is used for active monitoring of network performance, such as delay and jitter. It is not used for interface up/down status. DNA Center Assurance uses device health metrics, not IP SLA, for interface status. This option is incorrect because it misuses IP SLA.

Use the Network Hierarchy to assign the switch to a site and enable SNMP traps for linkDown on the switch.

Why it fails: While SNMP traps can be configured on the switch to send linkDown alerts, this is a device-level configuration, not a DNA Center Assurance feature. DNA Center Assurance provides centralized monitoring and policy-based alerts. The question asks for the DNA Center feature, so this is not the best answer.

On the vManage, use the 'show control connections' command to display the status of control connections.

Why it fails: vManage does not have a 'show control connections' CLI command; it is a management platform with a GUI. The status is viewed through the dashboard, not via CLI. This option is incorrect because it misrepresents the vManage interface.

On the vSmart controller, use the 'show control connections' command to display connections to vEdge routers.

Why it fails: While vSmart controllers do have a 'show control connections' command, it displays connections from the vSmart perspective. However, the question asks for actions to verify control connection status from the vEdge perspective or centrally. The vSmart command is less direct for troubleshooting a specific vEdge issue, and it may not show all details. The better choices are on the vEdge or vManage.

On the vEdge router, use the 'show control connections-history' command to view the history of control connection attempts.

Why it fails: The 'show control connections-history' command is not a valid command on vEdge routers. The correct command to view history might be 'show control connections-history' on vSmart, but not on vEdge. This option is incorrect because it references a non-existent command for vEdge.

show interface GigabitEthernet0/0

Why it fails: This command shows the interface status, line protocol, and hardware counters, but it does not display the IP MTU. It might show the interface MTU (which is typically 1500), but the IP MTU could be configured differently. For OSPF EXSTART issues, the IP MTU is the relevant value, so this command does not provide the needed information.

show ip ospf interface GigabitEthernet0/0

Why it fails: This command displays OSPF-specific interface parameters such as area, network type, cost, and timer intervals. It does not show the IP MTU. While it can help verify OSPF settings, it cannot confirm an MTU mismatch, which is a common cause of EXSTART state. Therefore, it is not the correct choice for this scenario.

show run interface GigabitEthernet0/0

Why it fails: This command displays the running configuration for the interface, which might include an explicit 'ip mtu' command if configured. However, if the MTU is left at default, it will not appear in the configuration. Since the default MTU can differ from the neighbor's configured MTU, relying on the running config alone may not reveal the mismatch. Thus, it is not the most reliable command.