Running a path search query in Forward Networks and getting zero results or unexpected results can be frustrating, especially when you're confident the query is correctly structured. Zero results typically indicate a mismatch between the query and the network model, incomplete data, or overly restrictive filters. Here’s a practical guide to troubleshooting and resolving these scenarios.

1. Investigate the Starting Point

A common reason for zero results is an issue locating the source IP:

• Check if the source IP was resolved correctly: Hover over the source IP to see if it was mapped to a host, device, or interface.
• If the system couldn’t locate the source:
  • Search for the address used in the “from” clause. Do you see a subnet containing the source? If the gateway on which this address resides is missing from the snapshot, add it to the snapshot.

    

  • If the source gateway cannot be added, consider using Edge Node and connect it to the right entry point for the subnet it represents. This will help the system locate the address and the broader subnet.

    

     

    

2. Verify the Destination

If using the To IP clause, ensure the system correctly resolved the destination IP:

• Hover over the destination IP to confirm its location.
• If the system can’t resolve the destination, follow a similar approach as step 1 to either add the devices hosting the destination IP, or add an Edge Node.

3. Use the Permit All Option

Firewalls and ACLs might block the traffic you're querying. To bypass these restrictions temporarily:

• Add the Permit All keyword to your query.
• This will allow the system to trace paths without enforcing firewall or ACL rules.

4. Reevaluate To and Through Filters

Filters like To and Through restrict the results. You may expect your query to pass through a middle box, or terminate at a certain device. If that doesn’t happen, either because of network misconfiguration or missing devices in the snapshot, then your query won’t match on any computed path and returns no results. In that case:

• Temporarily remove these filters and re-run the query.
• If results appear, adjust or simplify the filters to refine your query.

5. Review Traffic Filters

Traffic filters are applied by default to reduce irrelevant results. However, they can sometimes hide desired paths:

1. Open the Filters panel in the UI.
2. Under Traffic to Exclude, uncheck all filters, especially:
   • Misconfigured Gateway.
   • Glean Traffic.
3. The query will be refreshed automatically and may produce the desired path. File a support ticket so Forward Networks can fix the filter to match your desired behavior.

If you see some results, but they don’t match what you expected, there are a few additional things that need to be explored:

1. Double-Check Your Query

Before diving into deeper troubleshooting:

• Verify your query includes the correct source and destination IP addresses. One common mistake is understanding whether the destination IP is pre-NAT or post-NAT. This post is a great explanation on how to handle this in path search.
• Ensure the protocol (e.g., TCP, UDP, ICMP) is explicitly stated if needed. A common mistake is to specify HTTP as port or app-id, and leaving protocol unspecified. Since HTTP can run on both TCP and UDP in the modern era, the system will explore both and show the results for both.
• Include ports or application-specific details (e.g., port 443 for HTTPS).

2. Check for Missing Devices in the Model

If the path you expect is A → B → C → D, but the Forward platform returns only A → B, it could be

• C is missing in the snapshot. The path panel suggests when this happens and asks you to add the missing device.

• The link from B to C could be missing in the model. Please file a support ticket in such cases, but you can work around the issue by creating a manual link between B and C

3. Identify Drops or Divergences

• If paths terminate prematurely, check where the traffic diverges or drops:
  • Look for the last point of agreement between the expected and Forward’s computed paths.
  • Check sample packets at divergence points for headers that do not match what you intended the query to use (e.g., protocol is UDP, but you expected TCP. Please see step 1).
  • File a support ticket if needed.

Seek Support if Needed

If you’ve tried these steps and still don’t see results:

• Document your query, expected behavior, and findings.
• Include external data (e.g., traceroute outputs) for comparison.
• Include a full or subset snapshot (if you are not on fwd.app).
• File a support ticket with Forward Networks to get additional help.

Proactive tip for ensuring accurate path search results

• Validate Data Collection: Ensure all relevant devices, interfaces, and links are included in the snapshot.
• Train Your Team: Provide guidance on using Destination IP vs To and specifying protocols.
• Enhance the Model: Regularly update the snapshot to reflect changes in your network.