Troubleshooting Scenario Questions

Authentication token is missing.

Why it fails: A missing authentication token yields 401 Unauthorized, not 409 Conflict. It is tempting because authentication failures are common RESTCONF issues, and it would be correct when credentials are absent or expired, but 409 signals a resource-state conflict such as a duplicate or concurrent edit.

The resource does not exist.

Why it fails: A missing resource yields 404 Not Found, because the URI path resolves to no existing target. It tempts because developers frequently hit absent paths when first testing RESTCONF, but that condition is reported as 404. A 409 Conflict instead signals a state clash, such as a duplicate create or a lock violation.

The request contains invalid data types.

Why it fails: Invalid data types produce a 400 Bad Request, since the server rejects malformed or wrongly typed payload values during schema validation. It tempts because YANG type mismatches are a common RESTCONF error, but they map to 400, not 409. A 409 arises from a state conflict, such as creating a resource that already exists.

docker inspect web

Why it fails: docker inspect shows detailed configuration but not necessarily the logs of why the container exited.

docker exec -it web bash

Why it fails: docker exec cannot be used on a stopped container.

The device requires authentication via SSH keys but password was used.

Why it fails: SSH key versus password authentication is settled during the SSH handshake; since that connection succeeded, credentials are not the cause of the missing capability exchange. Key-based authentication is the correct choice when password logins are disabled by policy.

The firewall is blocking port 830.

Why it fails: Port 830 carries NETCONF over SSH, but the stem states the SSH connection succeeded, so the firewall is not blocking the session. Firewall rules on port 830 are the correct focus when the TCP connection itself cannot be established.

The device is running an older IOS version that does not support NETCONF.

Why it fails: IOS XE releases that support NETCONF are widely deployed, and the SSH transport already succeeded, so an unsupported version would not explain the missing capability exchange. Version checks are relevant when SSH itself fails or the NETCONF subsystem is absent from the image.

Request a higher rate limit from the Webex API support team.

Why it fails: A support-requested increase is slow, discretionary and unnecessary: the bot's 5-per-second average already sits under the 10-per-second limit, so only the spikes need smoothing. Raising limits is the right answer when sustained legitimate demand genuinely exceeds the published ceiling.

Catch HTTP 429 (Too Many Requests) errors and immediately retry the request.

Why it fails: Immediate retries during a 15-per-second spike compound the breach, since the API keeps rejecting until the window resets; 429 handling needs exponential backoff with jitter. Retry-on-429 is correct for transient throttling under a limit the workload otherwise respects.

Reduce the bot's overall request rate to 5 per second to stay well within the limit.

Why it fails: Throttling the whole bot to 5 per second discards the headroom the 10-per-second limit already permits, degrading responsiveness during normal load. It would be correct if average demand exceeded the ceiling. The spikes need buffering or backoff, not a permanent rate cut.

The server is unavailable due to maintenance

Why it fails: A 404 means the server received the request but found no matching resource at that URI; maintenance typically yields 503 Service Unavailable. It is tempting because an unreachable or downed server can surface as a client-side failure, but that scenario produces connection errors or 5xx responses, not 404.

The server encountered an internal error

Why it fails: A 500-class status signals server-side failure processing a valid request, whereas 404 indicates the requested resource was not found. It is tempting because both are server-generated responses, but internal errors map to 500 Internal Server Error, so this misattributes the cause.

The client lacks proper authentication

Why it fails: Missing or invalid credentials produce 401 Unauthorized (or 403 Forbidden when authenticated but not permitted), not 404. It is tempting because authentication failures block access to resources, but the server has already located the endpoint; 404 specifically means the URI or resource does not exist.

The data node is read-only

Why it fails: Read-only would return a 405 Method Not Allowed or 403.

Authentication failure

Why it fails: Authentication failure returns 401 Unauthorized.

The YANG model version mismatch

Why it fails: Model mismatch would typically yield a 400 Bad Request.

Layer 4 - Transport

Why it fails: Layer 4 manages end-to-end delivery, segmentation, and port-based multiplexing between hosts; it does not determine the hop-by-hop path packets traverse. It is tempting because transport protocols reveal connectivity and port failures, making Layer 4 correct when troubleshooting sessions rather than routing paths.

Layer 1 - Physical

Why it fails: Layer 1 governs transmission of raw bits across the physical medium, so it cannot forward or route packets between networks. It is tempting because cabling and interface faults genuinely cause connectivity loss, making Layer 1 the right focus when diagnosing link, signal or duplex problems rather than path verification.

Layer 2 - Data Link

Why it fails: Layer 2 forwards frames within a single broadcast domain using MAC addresses, so it cannot route packets between networks or select a path to a remote destination IP. It is tempting because switching is often confused with routing; Layer 2 would be correct for local frame delivery within one subnet.

Check application layer, then transport layer, then network layer, then data link layer, then physical layer.

Why it fails: This is a top-down approach, which is not from bottom to top as required. It starts with higher layers, missing lower-layer issues first.

Check physical cables and interfaces, then verify network layer, then verify transport layer, then verify application layer, skipping data link layer.

Why it fails: This skips the data link layer, which is crucial for verifying MAC addressing and switching. Missing a layer can lead to incomplete troubleshooting.

Check network layer first, then physical cables and interfaces, then data link layer, then transport layer, then application layer.

Why it fails: This starts with network layer instead of physical, which is out of order. Physical layer issues must be ruled out first in bottom-up troubleshooting.

The network device is unreachable

Why it fails: An unreachable device yields connection timeouts or 5xx responses from DNA Center, not 401, which signals failed authentication. Reachability checks are tempting when API calls fail, but they belong to connectivity troubleshooting; 401 specifically means the token or credentials were rejected.

The request body is invalid

Why it fails: An invalid request body returns 400 Bad Request after authentication succeeds, because the payload fails validation; 401 is raised before the body is processed. Schema checking is tempting when requests fail, but it applies once credentials are accepted, not when authentication itself is rejected.

The API endpoint is incorrect

Why it fails: An incorrect endpoint returns 404 Not Found, since the path cannot be matched, whereas 401 indicates the request reached a protected resource but lacked valid credentials. Verifying URLs is tempting when debugging API calls, but endpoint validation addresses routing, not authentication failures.

show ip interface

Why it fails: The show ip interface command displays IP interface status and may show which ACLs are applied to interfaces, but it does not show the contents of the ACLs or whether they are matching traffic. It can indicate that an ACL is applied, but to verify if it is blocking specific traffic, the engineer must examine the ACL entries and potentially use debug or logging. This command alone is insufficient for the task.

show ip route 203.0.113.10

Why it fails: The show ip route command displays the routing table entry for the destination, which can confirm if a route exists. However, it does not show ACL configurations or whether traffic is being filtered. While useful for verifying reachability at Layer 3, it does not address the suspicion of an ACL blocking traffic. The engineer needs to inspect ACLs, not just routing.

debug ip packet

Why it fails: The debug ip packet command can show IP packets as they are processed, but it is very resource-intensive and can severely impact router performance, especially in production. It may not directly show ACL matches and is not the recommended first step for verifying ACL blocks. While it can provide detailed information, it is generally used with caution and often with an ACL filter to limit output. It is not the best choice for this scenario.

Increase the ansible_port value to 830 to enable configuration over SSH.

Why it fails: Port 830 is the default for NETCONF over SSH, not for the CLI-based network_cli transport, which connects on port 22. Changing the port to 830 for IOS XE devices managed with network_cli would cause connection failures because the device is not listening for CLI sessions there. This action misidentifies the transport and would not resolve configuration application problems.

Configure ansible_become_method to enable and use sudo on the device.

Why it fails: Cisco IOS XE does not use sudo; privilege escalation is handled through the enable mode and the ansible_become and ansible_become_method settings configured for the network platform. Applying sudo semantics to a network operating system is incorrect and would not grant the privileges needed to enter configuration mode. The correct approach is to supply enable credentials through the appropriate network variables.

Set ansible_connection to local and run all modules on the control node.

Why it fails: The local connection runs tasks on the Ansible control node itself rather than on the target device. While legacy provider-based modules sometimes ran locally, modern network modules expect a persistent connection to the device through network_cli. Forcing local execution would cause configuration tasks to target the control node's environment, not the IOS XE device, and the playbook would not apply changes as intended.

The handshake uses UDP for faster negotiation

Why it fails: TLS typically runs over TCP.

The client must present a certificate to the server

Why it fails: Client certificates are optional, not required for a basic TLS handshake.

The client must have a public key to encrypt the session

Why it fails: The client uses the server's public key (from certificate) to encrypt the pre-master secret.

Increase the timeout value for the HTTP request.

Why it fails: Timeout values govern how long the client waits for a response; the server replied promptly with HTTP 400 and a JSON parse error, so latency plays no part. Raising timeouts is tempting when requests fail intermittently, but that scenario manifests as connection or read timeouts, not a syntax error at a character position.

Check the API key validity in the header.

Why it fails: An invalid or missing API key produces HTTP 401 or 403, not 400, and the response body already pinpoints a JSON syntax fault at position 42. Checking credentials is tempting because authentication failures are frequent causes of failed API calls, but that scenario would not return a parser token error.

Review the API documentation for required fields.

Why it fails: Documentation lists required fields, but the error explicitly reports invalid JSON syntax at position 42, so field presence is irrelevant. It is tempting because missing or malformed fields commonly cause HTTP 400 responses; however, that scenario returns schema-validation messages, not a parser token error naming a character offset.

show interfaces trunk

Why it fails: show interfaces trunk reports trunk encapsulation, allowed and active VLANs and pruning, which concerns Layer 2 links carrying multiple VLANs, not inter-VLAN forwarding. It is tempting because trunk misconfiguration commonly breaks VLAN connectivity, but it would be correct when verifying that a trunk carries VLAN 10 and VLAN 20 between switches.

show vlan

Why it fails: show vlan lists VLAN membership and port assignments, confirming VLAN existence and access-port placement rather than inter-VLAN routing. It is tempting because it quickly verifies VLAN 10 and VLAN 20 are configured, but it would be correct when checking that access ports are assigned to the intended VLANs.

show mac address-table

Why it fails: show mac address-table lists MAC-to-port-to-VLAN mappings, confirming Layer 2 learning only; it cannot show whether the switch routes between VLAN 10 and VLAN 20. It is tempting because it verifies host reachability at Layer 2, but it would be correct when locating which port a specific MAC address was learned on.

The MTU is misconfigured on the outgoing interface.

Why it fails: MTU issues cause packet drops but not ARP incompleteness.

The routing protocol has not converged yet.

Why it fails: An incomplete ARP entry means the router cannot resolve the next-hop MAC address, so frames are dropped regardless of routing convergence. Non-convergence would show a missing or wrong route, not an unresolved layer-2 mapping; it is tempting because both halt forwarding.

An ACL is blocking traffic on the outgoing interface.

Why it fails: An incomplete ARP entry means the router cannot resolve the next-hop MAC address, so frames are never transmitted; an ACL would show drops on a completed path, not unresolved ARP. ACLs are tempting because they also cause silent packet loss, and would be correct if ARP resolved but traffic were filtered.