Domain 3 Answer Key

From the figure, we can observe that the spike in latency is caused by the link between devices 10.84.30.1 and 10.87.10.253. Comparing the discovered network path between prior the incident and during the incident, we can confirm that no routing changes occurred as traffic always goes through these nodes. This is likely a network congestion or traffic load condition.

A valid next step is to review the bandwidth utilization and QoS settings at this site, to identify any possible network congestion conditions.

From the figures, we can observe that in normal conditions, traffic is forwarded from node 10.87.7.51 to 10.84.50.53. During the incident, there is forwarding loss observed at node 10.87.7.51. A Cisco ThousandEyes Enterprise Agent will display the “-“ character in the Table view when it is unable to complete measurements for a test.

This doesn't invalidate the test; it shows that data collection from one target agent wasn't completed. Instead of discarding the test, we should focus on other layers. Other agents measure expected MOS to this target, except the one at site 20, there may be issues specific to the target agent at site 20 that need attention.

Let's break down why the correct answer is the most indicative of a DNS issue that happened:

• A) The test target stopped responding - the error says "The host name could not be resolved", the test target response happens after it is resolved. This is not a correct answer.
• B) The FQDN of the test target is non-existent – this answer is not correct because the FQDN exists in the previous test round.

• D) The DNS settings on the endpoint are incorrect – this answer is also incorrect because in the previous round the end-point was using the same DNS settings and the issue did not happen.

• Correct answer: C) The DNS servers assigned to the endpoint are unreachable. This is likely because the endpoint is utilizing external DNS servers (8.8.8.8, 8.8.4.4), but based on the exhibit, external tracing is absent, meaning external resources are unreachable.

According to the log message, there was a timeout when attempting to connect to c1.eb.thousandeyes.com:

2024-05-07 13:20:28.498 DEBUG [3068.2148] net.WinHttpClient@WinHttpClient.cpp:2115 - Request to: wss://c1.eb.thousandeyes.com/relay/connect timed out: 12002: The operation timed out
2024-05-07 13:20:28.499 DEBUG [3068.8240] net.WinHttpClient@WinHttpClient.cpp:2115 - Request to: https://c1.eb.thousandeyes.com/status.json timed out: 12002: The operation timed out

• Option A is incorrect because the new endpoint should function properly in the new network like other endpoints.
• Option B is incorrect because reinstalling the software does not address IP issues.
• Option C is incorrect because incorrect IP credentials manually entered will not resolve automatically.

This one is a tricky one, as it requires you to have a basic understanding of HTTP response codes (see Resources), let's have a look at each potential answer.

• A) Modify the firewall rules to allow connections to the target domain is incorrect because our exhibit shows we are getting a response from the target server
• C) Change the HTTP request method to PATCH is incorrect because nothing in the response header indicates that the request method is incorrect (that would be code 405 Method Not Allowed)
• D) Modify the target URL to an available API endpoint is incorrect because nothing in the response points to an unavailable API endpoint

Finally, if we check the response code we are getting from the server, 401, we will find it to be a response to Unauthorized requests. Further inspection into the request headers will confirm the issue, as no Authentication header is being sent, thus, Modify the authentication credentials is the answer.

This one will also leverage your knowledge of HTTP response codes, albeit with a twist.

• There is a network connectivity problem preventing us from reaching the target URL is incorrect because our exhibit shows we are getting a response from the target server

• One of the DOM elements cannot be found in the server is incorrect because even though the waterfall chart is marking component 81 with an issue, we don't see any 404 Not Found response

• The request timed out waiting for the server to respond is incorrect because the exhibit shows the server answering promptly to almost all component requests

Finally, if we check the response code we are getting from the server, we will find it to be a 302 Found redirect. The fact that each redirect is leading to another redirect (multiple 302 responses in a row) points to a misconfiguration on the server that is causing a loop within the app. Thus, the last option is correct:

While the exhibits clearly depict a network issue with significant packet loss, pinpointing the exact cause as a BGP hijack requires careful analysis. Let's break down why the correct answer is the most indicative of a BGP hijack:

• Availability Drop: Although a drop in availability is a symptom of the problem, it doesn't specifically point to BGP hijacking. Various network issues could cause availability drops.
• HTTP Server response delay: Similar to availability drop, this is a symptom of the problem, likely caused by the packet loss, but it doesn't explicitly indicate BGP hijacking.
• Packet Loss: Again, this is a clear symptom shown in the exhibits but doesn't directly confirm BGP hijacking as the cause.

However, the change in AS path from AS 16509 to AS 10297 is a strong indicator of BGP hijacking. This suggests that the route to the destination was illegitimately taken over by another AS, causing traffic to be misdirected and resulting in packet loss.

The shift in the AS path provides the most concrete evidence supporting the possibility of a BGP hijack in this scenario.

The exhibits show a significant packet loss issue occurring at a specific point in the network path. The Path Visualization highlights a node within AS 10297 as the source of 100% forwarding loss for multiple agent locations. This suggests a problem beyond the local network and points towards a potential BGP routing issue, specifically a BGP hijack.

Thus, the correct answer is B) Reach out to the ISP to report the suspected BGP hijacking incident

Here's why the other options are not the best next steps:

• Contact the internal network team to investigate potential misconfigurations on the local routers is incorrect because the issue appears to be external to the local network, as multiple geographically dispersed agents are affected, and the packet loss originates from AS 10297.
• Implement traffic filtering rules on the firewall to block traffic originating from AS 10297 is incorrect as implementing firewall rules would not address the root cause, which is likely a routing issue outside of the local network's control.
• Restart the DNS server to refresh its cache and potentially resolve the observed issue is incorrect because restarting the DNS server is unlikely to resolve a BGP hijacking issue, as the problem lies within the routing of traffic rather than the DNS server itself.