Skip to main content

Running Path Analysis

[Why This Page Exists]

If you’ve already gone through Getting Started / First Steps, you know how to:

  • Open Path Analysis
  • Enter a simple query
  • View and inspect results

That is enough to get value quickly. This page exists for a different reason.

Path Analysis is not just a “search bar” — it is a language for expressing intent about network behavior.
The language is powerful, flexible, and deliberately permissive. That power allows you to describe almost any scenario, but it also means that how you phrase a query has a direct impact on how useful the results are.

This page is meant to help you:

  • Think clearly about what question you’re actually asking
  • Translate that question into a well-structured path query
  • Gain a high-level understanding of how the engine interprets anchors, constraints, filters, and modes
  • Build queries incrementally and confidently, without guessing

If First Steps showed you that Path Analysis works, this page teaches you how to work with it intentionally.

When You Should Use Path Analysis​

Path Analysis is useful whenever you want to reason about how the network behaves, not just what is configured on individual devices.

It is particularly valuable when the answer depends on the combined effect of routing, Layer-2 forwarding, security policy, and encapsulation — situations where reading configuration line by line is not enough.

Typical questions Path Analysis helps answer include:

Basic Reachability and Connectivity​

  • Can traffic get from this source to this destination at all?
  • Is the path symmetric, or does traffic return via a different route?
  • Is the lack of connectivity due to missing routing, policy, or something else?

These questions often arise when troubleshooting application connectivity or validating expected communication paths.

Device and Interface Involvement​

  • Which devices and interfaces would forward this traffic?
  • Does traffic enter or exit the network through the expected device or interface?
  • Is traffic traversing a device that it shouldn’t?

These scenarios are common when validating design assumptions or understanding unexpected traffic patterns.

Security and Policy Validation​

  • Does traffic traverse (or bypass) a firewall, IPS, or inspection point?
  • Is there any alternate path that avoids enforcement?
  • Which ACL, firewall policy, or NAT rule applies to this traffic?

Path Analysis helps answer these questions by showing both the path and the policy decisions applied along it.

Traffic Drops and Failures​

  • Where exactly is this traffic being dropped?
  • Is the drop caused by an ACL, firewall policy, routing decision, or missing adjacency?
  • What configuration or state caused the drop?

Rather than inferring from logs or counters, Path Analysis lets you trace the modeled decision directly.

Traffic Type–Specific Behavior​

  • How does HTTPS REST traffic flow between these endpoints?
  • Does traffic on a specific port or protocol follow a different path?
  • Do application- or identity-based rules affect this traffic?

These questions are especially relevant in environments with layered security controls or application-aware policies.

Interaction Between Routing and Security​

  • Does routing send traffic to the firewall that enforces policy?
  • Is traffic routed correctly but blocked by policy?
  • Would traffic be deliverable if security policy were not enforced?

Path Analysis helps separate connectivity issues from policy issues, especially when combined with permit-all mode.

Broader Exploration and Exposure Analysis​

  • What destinations are reachable from this host or subnet?
  • Which parts of the network are exposed from this source?
  • What is the effective blast radius of a compromised endpoint?

Because Path Analysis does not rely on observed traffic, it can answer these questions even for flows that rarely or never occur.

tip

Before writing a query, it’s worth stating the question out loud or in plain text.

If the question itself is unclear, the query almost certainly will be as well.
Clear intent leads to clearer queries — and clearer results.

Launching Path Analysis and Snapshot Context​

To run a path search:

  1. Navigate to Search
  2. Select Path Analysis
  3. Choose the snapshot you want to analyze

Every path search is evaluated entirely within the context of the selected snapshot.
The results show how the network would forward traffic, based on the configuration and state captured at that moment in time.

Path Analysis does not:

  • Predict future behavior
  • Evaluate uncollected configuration
  • Depend on observed traffic

It strictly evaluates the modeled behavior of the network as collected.

How to Think About a Path Query​

A path query is easiest to reason about if you separate it into three conceptual layers:

  1. Anchors — where traffic starts and (optionally) ends
  2. Constraints — which paths are allowed or disallowed
  3. Context — what kind of traffic is being modeled

You do not need to explicitly specify all three in every query, but every query implicitly relies on them.

Most confusion arises when:

  • Anchors are vague or missing
    The query does not clearly establish where traffic starts (and often where it is expected to end), making it difficult to interpret the resulting paths.

  • Constraints are added before basic reachability is understood
    Adding constraints such as through(), ingress(), or bypass() too early can unintentionally exclude valid paths, making it appear as though no connectivity exists. It is usually more effective to first confirm that paths exist at all, and then add constraints incrementally to narrow the investigation.

  • Context is assumed rather than specified
    Implicit assumptions about VRFs, interfaces, security zones, or traffic type can lead to misleading results if those assumptions do not match the modeled network state.

Defining How Paths Are Selected: Anchors and Constraints​

A path search ultimately needs enough context for the engine to determine where traffic is evaluated and which paths should be included in the results.

Some operators explicitly define the start or end of traffic, while others constrain paths based on where traffic enters, exits, or traverses devices.

Anchors: Defining Start and End of Traffic​

Certain operators explicitly anchor the beginning or end of traffic in the network model.

Anchor Functions​

The following functions define explicit anchors:

  • from(), Specifies where traffic originates.
    If used, from() must appear at the beginning of the query. from() anchors the path at the inferred (localized) starting location of the source.

  • to(), Specifies where traffic is intended to be delivered.
    If used, to() must appear at the end of the query. to() anchors the path at the inferred (localized) delivery location of the destination.

A query does not have to include from() or to().
However, the system must still be able to infer a starting point for traffic evaluation, either explicitly or implicitly.

A starting anchor is therefore always required; an ending anchor is optional, but strongly recommended.

tip

Queries without an explicit destination can be valid, but they often produce:

  • Large result sets
  • Broad path groups
  • Results that are harder to interpret

For most investigations, anchoring both the start and the end produces clearer, more actionable results.

Positional Constraints: Refining Where Paths Pass​

Other operators do not define a global start or end of traffic.
Instead, they constrain the result set based on where traffic enters, exits, or traverses devices within a path.

These operators can be used on their own or in combination with explicit anchors.

ingress()​

Constrains the search to paths where traffic ingresses the specified device or interface at that point in the path.

ingress():

  • Does not imply a network edge or boundary
  • Filters indexed paths based on where traffic enters a device
  • May appear multiple times in a query. When specified more than once, matching paths must ingress each listed device or interface in the order they appear in the query.
  • Can be used with or without from()

When used without from(), ingress() still acts as a waypoint constraint and does not define where traffic originates at the network level.

egress()​

Constrains the search to paths where traffic egresses the specified device or interface at that point in the path.

Like ingress():

  • It does not imply exiting the network
  • It filters paths based on where traffic exits a device
  • It may appear multiple times in a query. When specified more than once, matching paths must egress each listed device or interface in the order they appear in the query.
  • It can be used independently or alongside other operators

through() and bypass()​

These functions do not define anchors.
They act purely as path constraints.

  • through()
    Requires that matching paths include specific devices or interfaces.
    • May appear multiple times in a query.
    • When specified more than once, matching paths must traverse through each listed device or interface in the order they appear in the query.
  • bypass()
    Requires that matching paths avoid specific devices or interfaces.
    • May appear multiple times in a query.
    • Unlike other constraints, the order in which bypass() appears does not affect evaluation

Examples:

from(A) through(fw-prod-01) to(B)

from(A) to(B) bypass(wan-edge-2)

These constraints are commonly used to:

  • Validate security intent
  • Detect unintended alternate paths
  • Confirm enforcement points

A good practice is to add constraints only after confirming basic reachability.

Using Ingress and Egress as Constraints​

Because ingress() and egress() are positional rather than directional, they are often used as additional constraints, even when from() and to() are present.

tip

A directional constraint defines where traffic starts or ends in the network (for example, from() or to()), giving the path a clear direction.

A positional constraint filters paths based on where traffic enters, exits, passes through, or explicitly avoids devices or interfaces (for example, ingress(), egress(), through(), or bypass()).

Examples:

from(A) ingress(core-1) to(B)

ingress(core-1 xe-0/0/1) egress(edge-fw xe-0/0/2)

These patterns are useful when:

  • Traffic may originate from multiple locations
  • You want to validate specific entry or exit points
  • You are reasoning about asymmetric routing or policy enforcement

IP Localization: How Anchors Are Resolved​

When an anchor refers to a host, IP address, or prefix, Forward uses IP localization to determine where in the modeled network traffic should be injected or delivered.

IP localization evaluates multiple sources of collected data, including:

  • Interface addresses and subnet membership
  • ARP and ND tables
  • MAC address tables and Layer-2 adjacency
  • Routing and next-hop resolution
  • Vendor- and platform-specific behaviors

The goal is to place the anchor at the most accurate device and interface available in the snapshot.

If multiple valid locations exist, the query may require additional scoping (for example, using at() or in()) to remove ambiguity.

Importantly:

  • The referenced host does not need to be a managed device
  • The anchor represents where traffic enters or exits the model, not the host itself

Translating Semantic Intent into Path Queries​

Path Analysis queries are most effective when you start by clearly stating what you want to find out, and then translate that into a query—rather than starting with query syntax and hoping it produces the right result.

In other words, the question you are trying to answer should exist before you start typing operators into the search bar. The query language is expressive enough to encode almost any networking question, but it will not infer your intent for you.

A useful way to approach path queries is to move through the following steps deliberately:

  1. Clearly state the question you want answered
  2. Decide what must be anchored versus what should be modeled as packet attributes
  3. Add constraints only when they meaningfully narrow the question
  4. Validate results incrementally before refining further

This section walks through common intent patterns and shows how to translate each one into a query that accurately reflects what you are trying to understand.

Basic Reachability​

Intent (what users often mean):
“Starting from host A, what happens to traffic whose destination is B?”

In Path Analysis, there are two different ways to express this intent, and they have different semantics and different results.

Option 1: Anchor both source and destination​

from(172.17.23.34) to(172.17.20.16)

What this means:

  • from(172.17.23.34) anchors the start of the path at the inferred (localized) location of the source host.
  • to(172.17.20.16) anchors the end of the path at the inferred (localized) location of the destination host.

For a path to match this query:

  • Traffic must terminate at the inferred location of 172.17.20.16.
  • The destination IP address in the packet header at the final egress (or network exit) must be 172.17.20.16 knowing that NAT could have occurred earlier in the path.

Importantly, when evaluating this query:

  • The engine does not require the destination IP address at the initial ingress into the network to be 172.17.20.16.
  • The destination IP may have been translated in transit (for example, via destination NAT), as long as the packet ultimately exits the network with destination IP 172.17.20.16 and is delivered to its inferred location.

This query asks:

“Are there paths where traffic, starting from host A, ultimately arrives at the inferred location of host B with a destination IP of B?”

This formulation is appropriate when you want to reason about end-to-end reachability between two concrete endpoints, regardless of any translations that may occur along the way.

Option 2: Anchor the source, constrain the destination header​

from(172.17.23.34) dest-ip(172.17.20.16)

(or equivalently: ipv4_dst.172.17.20.16)

What this means:

  • The source is anchored at the inferred location of host A.
  • The destination IP is set in the initial packet header.
  • The path is not anchored to the inferred location of 172.17.20.16.

For this query:

  • Traffic must start with destination IP 172.17.20.16 at ingress.
  • The packet may be translated, redirected, or load-balanced as it traverses the network.
  • The final delivery location does not have to correspond to the inferred location of 172.17.20.16.

This query asks:

“If host A sends traffic with destination IP 172.17.20.16, how does the network process and forward that traffic, and where does it end up?”

note

Conceptually, this is similar to running a traceroute from host A toward the destination IP, except that Path Analysis evaluates all applicable protocols and forwarding behavior, not just ICMP.

This formulation more closely reflects how packets behave in real networks, especially in environments with NAT, load balancers, or virtual IPs.

Why the Results Can Be Very Different​

Because of these differences:

  • from(A) to(B)
    → constrains paths to those that end at B’s inferred location and exit the network with destination IP address B.
  • from(A) dest-ip(B)
    → constrains only the initial packet header, allowing the network to decide where traffic is ultimately delivered.

As a result, the two queries can return very different sets of paths, especially in networks with address translation or traffic steering.

[Practical Guidance]
  • Use to() when you want to validate delivery to a specific endpoint.
  • Use dest-ip() when you want to understand how traffic addressed to a given IP is handled by the network.

The UI prompt that appears while typing the query is intentionally highlighting this distinction, because choosing one over the other fundamentally changes the semantics of the search.

from-to, vs from-dst

Header Constraints and Where They Apply in a Query​

After you understand the difference between anchoring destinations (to()) and constraining packet headers (dest-ip()), the next important concept is where header constraints are applied within a path query.

Many packet header fields—such as destination IP, ports, protocol —can appear after the source anchor from(), after the destination anchor to(), or both***. Where these constraints appear in the query affects which parts of the path they apply to, and how the sample packet is constructed and evaluated.

[***]

Layer-7 and application-level header values (such as URL, app-ID or user-ID) are not permitted to be specified after the to() anchor.

Header Constraints After from()​

When header constraints appear after from() (or when from() is the only anchor), they apply to the initial packet as it enters the network.

For example:

from(A)(ipv4_dst.B)(tp_dst.443)

This means

  • Traffic starts at A’s inferred (localized) location in the network.
  • When the packet enters the network, its headers are explicitly defined:
    • Destination IP = B
    • Destination port = 443
  • From that point on, the network is free to handle the packet according to its configuration.

This means the destination IP and port are constraints on the packet at ingress, not guarantees about where the packet will ultimately be delivered.

As the packet moves through the network, it may be:

  • Translated (for example, via destination NAT)
  • Redirected (for example, to a load balancer or service)
  • Steered through specific devices or paths (policy-based routing, service chaining)

The final delivery location does not have to match the inferred location of IP B.

NOTE: In this form of query, header constraints describe what the packet looks like when it enters the network, while the network model determines where that packet is actually forwarded and delivered based on routing, NAT, load balancing, and policy.

This is why this approach often better reflects real-world packet behavior than anchoring the destination with to().

Header Constraints After to()​

When header constraints appear after to(), they apply to the packet as it exits the network and is delivered to the destination anchor.

For example:

from(A) to(B)(tp_dst.443)

This means:

  • Traffic must be delivered to B’s inferred location
  • At final egress, the packet must have destination port 443
  • The packet may have been translated earlier, as long as it meets the constraint at delivery

Here, the header constraint is interpreted as a delivery condition, not an ingress condition.

This placement is useful when:

  • You care about how traffic arrives at the destination
  • You want to validate post-NAT or post-policy behavior
  • You want to ensure the destination receives traffic with specific characteristics

Why Placement Matters​

The same constraint can mean different things depending on where it appears:

  • After from() → constrains the initial packet
  • After to() → constrains the delivered packet
  • In both places → constrains both ingress and delivery behavior

Because Path Analysis illustrates forwarding behavior using a representative sample packet, constraint placement directly affects:

  • Which header values are fixed at the start of the path
  • Which header values are evaluated at delivery
  • How header transformations (such as NAT) are reflected along the path

If a sample header value does not match what you expect, it could be a signal that:

  • The constraint was applied at a different point than intended, or
  • The network is legitimately modifying the packet in transit

Intent: “What can this host reach?”​

Intent:
“Starting from host A, what destinations are reachable?”

Query:

from(A)

What this means:

  • Traffic is anchored at host A’s inferred location
  • No destination anchor is specified
  • The engine returns all reachable paths from that starting point

This type of query is useful for:

  • Exposure analysis
  • Understanding blast radius
  • Exploring unexpected reachability

However, because this type of query is intentionally broad, it often:

  • Returns a very large number of paths
  • Produces many path groups
  • Reaches the configured limit on returned results before all possible paths are explored
[Practical Guidance]

In practice, such open-ended queries are usually followed by additional constraints or filters to narrow the scope.
If the goal is to comprehensively understand exposure from a source (for example, all reachable destinations), Blast Radius is typically a better fit than an unconstrained path search.

Intent: “Can traffic reach subnet or prefix X?”​

Intent:
“Is traffic deliverable to a particular subnet or address range?”

Query:

from(A) to(10.10.20.0/24)

What this does:

  • Anchors traffic at A
  • Anchors delivery to any inferred location associated with the prefix
  • Validates routing and reachability at the subnet level

This is useful when:

  • You don’t care about a specific host
  • You are validating network segmentation or routing boundaries

Intent: “Does traffic go through a specific device?”​

Intent:
“Is traffic between A and B forwarded through device X?”

Query:

from(A) through(deviceX) to(B)

What this does:

  • Anchors start and end locations
  • Filters results to only paths that include device X
  • Excludes all other paths

This is commonly used to:

  • Validate security enforcement
  • Confirm inspection points
  • Ensure design assumptions hold

Intent: “Is there any path that bypasses a specific device?”​

Intent:
“Can traffic avoid this firewall or router?”

Query:

from(A) bypass(deviceX) to(B)

What this does:

  • Anchors start and end locations
  • Returns only paths that do not traverse device X

This is a powerful way to:

  • Detect unintended alternate paths
  • Identify segmentation gaps
  • Validate redundancy design

Intent: “Does traffic from A exit a specific device through a particular interface?”​

Query:

from(A) egress(deviceY, interfaceZ)

What this does:

  • This query restricts results to paths where traffic egresses deviceY via interfaceZ at some point along the path.
  • It does not imply that this interface represents the edge of the network or the final exit point for traffic.

Intent: “Why is this specific traffic being dropped?”​

Example intent:
“Why is HTTPS traffic being dropped when it passes through this firewall?”

Query (expressed via UI + filters):

from(172.17.32.5) ingress(SJ-BLDG1-CM-NGFW-1)

Refine using filters:

  • Destination L4 port: HTTPS
  • Outcome: dropped

Selecting these filters augments the path query with the corresponding constraints, resulting in a query equivalent to:

from(172.17.32.5) ingress(SJ-BLDG1-CM-NGFW-1) (tp_dst.HTTPS) z(dropped)

Conceptually:

  • Anchors and positional operators (from, ingress) define where the traffic is evaluated
  • Filters constrain what the traffic is and how it behaves

This approach makes it easy to isolate dropped traffic without manually encoding every condition into the initial query.

Intent: “Is traffic failing because of policy enforcement, or because of underlying connectivity or forwarding issues?”​

A practical way to answer this question is to start with the simplest possible query and refine it incrementally.

A common workflow is:

  • Anchor the starting point and specify the destination IP address (for example, from(A)(dest-ip.B))
  • Observe how traffic is forwarded through the network and where it stops
  • Gradually add headers, constraints, or filters to narrow the investigation
  • If traffic is dropped, use permit-all mode to determine whether routing and switching would allow the traffic to continue in the absence of firewall or ACL enforcement

This approach avoids prematurely constraining the query and makes it easier to understand how the network behaves before policy is applied.

A Practical Guideline​

If you find yourself writing a query that feels complex or confusing, pause and ask:

  • What am I anchoring?
  • What am I constraining?
  • What am I trying to learn from the result?

Most effective queries are built incrementally, not all at once.