Skip to main content

Overview

Path Analysis — Overview​

Path Analysis allows you to understand how traffic would flow through your network, based on the actual configuration and state collected from your devices.

Instead of relying on live packet capture or simulated traffic injection, Forward builds a mathematical model of network behavior and uses it to trace feasible forwarding paths between endpoints.
This makes Path Analysis deterministic, repeatable, and safe to use for validation and troubleshooting.

What Path Analysis Does​

At a high level, Path Analysis answers questions such as:

  • Can traffic get from A to B?
  • Which devices and interfaces would forward it?
  • Where are routing, policy, or translation decisions applied?
  • Why is traffic delivered, dropped, or unreachable?

Beyond basic reachability, Path Analysis also provides detailed, per-hop insight into how the network would handle the traffic:

  • For each hop along a path, it shows which interfaces are used as ingress and egress, along with contextual information such as the VRF, security zones, and the routing or policy domain in effect.
  • It identifies which network functions are evaluated on each device (for example, Layer 2 switching, Layer 3 routing, PBR, ACLs, NAT, or firewall policy) and the result of each evaluation.
  • For every routing, policy, or translation decision, Path Analysis provides direct links to the source data that governs that behavior via “See device state” links.
    These links reference the exact configuration lines or collected state entries (such as routing tables, ARP/ND mappings, ACL rules, or NAT policies) that were used by the model.

Together, this allows you not only to see what path traffic would take, but also to understand why each forwarding or policy decision is made, grounded in the actual configuration and state collected from the network.

What Path Analysis Is Not​

It’s equally important to understand what Path Analysis does not do:

  • It does not simulate live traffic or replay packets.
  • It does not observe or infer behavior from flow logs or telemetry.
  • It does not predict*** future network behavior or evaluate uncollected configurations.
  • It does not modify*** network state or test changes that have not been collected.

Path Analysis always reflects how the network was behaving at the time the snapshot was taken, based strictly on the configuration and state present in that snapshot.

[***]

Although Path Analysis does not perform predictive analysis, certain evaluation modes (e.g. "permit-all mode") can present alternative outcomes based on the same collected snapshot. These modes allow the model to show how traffic would traverse the network if specific enforcement conditions (e.g. data-plane ACL, FW policy) were not applied. This does not represent a future network state or an uncollected change, but rather a different interpretation of the same underlying configuration and state.

What Path Analysis Is Useful For​

Because results come from a deterministic model of collected state, you can confidently use Path Analysis to:

  • Analyze current or historical network behavior
    Understand exactly how traffic was forwarded at the time of snapshot collection.
  • Troubleshoot reachability and policy issues
    Identify where traffic was delivered, dropped, or became unreachable — and why.
  • Explore hypothetical forwarding behavior by relaxing policy constraints
    For example, permit-all mode treats all ACLs and firewall policies as "permit rules" while modeling the end-to-end forwarding logic and any traffic header translations along the path including load balancing rules.
    This helps decouple policy enforcement from underlying connectivity during analysis.
  • Analyze traffic patterns that rarely occur in production
    Because the model does not depend on observed traffic, you can inspect paths for flows that are infrequent, transient, or difficult to capture with flow data. This includes security-oriented use cases, such as evaluating whether a host or service would be reachable from untrusted or external networks without generating live probes or test traffic. This makes it possible to assess exposure risk and potential attack paths proactively, using only the collected configuration and state.

Core Concepts​

Understanding a few core concepts will help you make sense of all Path Analysis results.

Anchors​

A path search ultimately needs to determine where traffic starts, and often where it ends. These locations are defined using anchors.

The following functions define anchors:

  • from() — specifies where traffic originates.
    • If used, it must appear at the beginning of the query.
  • to() — specifies where traffic is intended to be delivered.
    • If used, it must appear at the end of the query.

Anchors establish the directional frame of reference for the search by defining where traffic enters and (optionally) exits the modeled network.

A query does not have to include from() or to(). However, the system must still be able to resolve a starting point, either explicitly or implicitly based on the query.

Examples of valid queries:

  • from(ip-A) ipv4dest-X
  • from(ip-A) through(fw-A) to(ip-Z)
tip

Queries without an explicit destination are valid, but may produce broad result sets that are harder to reason about.

Constraints: Refining Which Paths Are Evaluated​

Functions such as ingress(), egress(), through(), and bypass() act as constraints that refine which paths are included in the result set.

Positional Constraints​

  • through()
    Requires matching paths to traverse specific devices or interfaces.
  • bypass()
    Requires matching paths to avoid specific devices or interfaces.
  • ingress()
    Requires matching paths where traffic enters a specific device or interface at that point in the path.
  • egress()
    Requires matching paths where traffic exits a specific device or interface at that point in the path.

These constraints:

  • Do not define where traffic originates or ultimately ends
  • Do not imply network-edge ingress or egress
  • May appear anywhere in the query
  • May be used multiple times

The key distinction is that ingress() and egress() add directionality at the device or interface level, while through() and bypass() are direction-agnostic.
However, none of these establish network-level ingress or egress in the way from() and to() do.

IP Localization (Anchor Resolution)​

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

IP localization is part of Forward’s behavioral model and 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 nuances

Using this information, Forward resolves anchors to the most accurate device and interface location available in the snapshot.

If multiple valid locations are possible, additional scoping (for example, using at() or in()) may be required to disambiguate the anchor.

[Note]

IP localization determines where traffic enters or exits the model.
The referenced host does not need to be a managed or collected device.

[Query Complexity]

Path Analysis supports a rich and expressive query language, and most operators can be combined freely. However, not every syntactically valid query is necessarily meaningful.

Before writing a query, it’s worth stepping back and asking what question you’re trying to answer.
Start with a clear intent (for example, “Can host A reach host B through this firewall?”), then add query clauses to express that intent.

While the syntax is powerful enough to model almost any scenario, overly complex or loosely anchored queries can produce results that are broad, confusing, or hard to interpret — especially for new users.

In practice, most effective queries are built incrementally: begin with a simple anchor, verify the result, then refine as needed.

The Sample Packet​

For each matching path, the UI displays a sample packet that illustrates how traffic is forwarded along that specific path.

The sample packet shows a representative set of header fields, which may include:

  • Layer-2 fields (MAC address, VLAN)
  • Layer-3 fields (IP address, protocol)
  • Layer-4 fields (ports, TCP flags)
  • Optional Layer-7 attributes (application ID, URL, user identity)

Filters and traffic defaults influence which header fields are relevant and therefore reflected in the sample packet. For each path the user selects, the UI chooses a representative packet to explain the forwarding decisions made along that path.

It’s important to note that the sample packet is illustrative, not prescriptive. Path Analysis evaluates all matching paths implied by the query and its constraints; the sample packet is shown to help explain the specific forwarding behavior, state, and configuration that apply to the selected path, including any header transformations such as NAT or encapsulation.

Sample packet respects all header values supplied by user as part of the query, and picks illustrative values for any header fields that were not specified. If a particular sample header value picked by the system is not relevant or desirable, you can always force the system to use a specific value by modifying the query directly.

Indexed Paths​

Rather than computing forwarding behavior from scratch for every search, Forward indexes feasible paths through the modeled network.

When you run a search:

  • Your query narrows the indexed paths using anchors, filters, and modes.
  • The engine deduplicates equivalent paths and organizes the results into path groups.
  • Each path group represents a set of paths that are functionally equivalent, even if they differ in lower-level details.

Path grouping considers factors such as:

  • Equal-Cost Multi-Path (ECMP) alternatives
  • Underlay variations for the same overlay path
  • Other forwarding nuances that do not materially change the outcome of the path

This grouping keeps results concise while preserving the ability to inspect individual paths when needed.

This design enables:

  • Fast search execution
  • Instant updates when filters change
  • Deterministic results for a given snapshot

Supported Traffic Types​

Path Analysis supports a wide range of forwarding behaviors, including:

  • Unicast traffic (most common use case)
  • Multicast forwarding, represented as distribution trees
  • Overlay networks (e.g. VXLAN, GRE, MPLS, etc)
  • Policy-based routing (PBR)
  • Tunnels and encapsulations

Overlay paths can be correlated with their underlay forwarding, allowing you to understand how logical paths map to physical transport.

In addition to Layer-2 and Layer-3 forwarding, Path Analysis also models Layer-7–aware policy behavior, such as:

  • Firewall rules that match on application, service or user identity
  • Load balancer policies that steer traffic based on Layer-7 attributes

Relationship to Other Forward Features​

Path Analysis is a core building block for several capabilities across the Forward platform.

Path Analysis is not just a troubleshooting tool, but a shared analytical foundation for validation, security analysis, and change impact assessment across the Forward platform.

Topology and Covered Topology​

When you navigate to Search, Forward displays the topology of the modeled network.
Path Analysis results are overlaid on top of this topology.

  • The highlighted portion of the topology represents the covered topology.
  • Covered topology is the union (superset) of all devices and links that could be traversed by any path within the resulting path groups.
  • This view provides immediate visual context for understanding where traffic may flow, not just a single hop-by-hop trace.

Covered topology helps answer questions like:

  • Which devices and links participate in forwarding this traffic?
  • Which parts of the network are relevant when troubleshooting connectivity issues or assessing the impact of configuration changes affecting this traffic?

Verify (Intent Checks)​

Path Analysis underpins Verify checks, including:

  • Existence checks — validating that a path exists between two endpoints.
  • Isolation checks — validating that no path exists between endpoints that must remain segmented.

Verify executes these checks each time a new snapshot is captured.
By re-running Path Analysis on every snapshot, Verify detects whether reachability or isolation intent has changed as the network configuration or state evolves.

Security Blast Radius​

Path Analysis is used to compute security blast radius — the set of destinations that are reachable from a given source IP, prefix, or endpoint.

In this context, blast radius answers questions such as:

  • If this host or subnet is compromised, what can it reach?
  • Which networks, services, or zones are exposed from this source?

Blast radius analysis relies on Path Analysis to evaluate reachability from the specified source across routing, ACLs, firewall policies, and security zones, based on the collected snapshot.

For more details, see Security → Blast Radius

Security Posture Matrix​

Security posture views rely on Path Analysis to evaluate:

  • Reachability between security zones or endpoint groups.
  • Whether traffic between zones is allowed, denied, or conditionally permitted.
  • Where enforcement occurs along the path.

This allows Forward to reason about effective security posture, not just configured policy.

Path Diff​

Path Analysis also powers Path Diff, which compares forwarding behavior across snapshots:

  • Highlighting changes in routing, policy, or translation behavior.
  • Showing how paths evolve over time as the network changes.

Path Diff relies on consistent path modeling to make differences meaningful and deterministic.

Scope and Limitations​

Path Analysis operates within the scope of a single snapshot:

  • Results reflect the configuration and state captured at that point in time.
  • Missing or uncollected devices may affect completeness.
  • Partial data is surfaced explicitly so results can be interpreted correctly.

Path Analysis answers “what the network would do” — not “what traffic actually did”.

Where to Go Next​

If you’re new to Path Analysis, start with:

If you’re ready to dive deeper:

  • Running a Path Analysis — how queries are built, refined, and executed
  • Filters & Traffic Defaults — shaping the sample packet and narrowing results
  • Understanding Results — interpreting hops, topology, and policy behavior