Skip to main content

Overview

Path Analysis evaluates how traffic would move through your network, given the configuration and state collected in a snapshot. The analysis is model-based. It does not send live traffic. Every result comes from the configuration and state Forward collected.

The model itself is deterministic. A query specific enough to return fewer than the result cap (5,000 paths by default) produces the same result every time it runs against the same snapshot. A broad query that exceeds the cap can see some variance in which paths appear, because the result is truncated to a bounded set.

This page covers the concepts the rest of the Path Analysis documentation builds on: what the analysis does and does not do, how queries resolve to locations in the model, and how results are organized.

What Path Analysis Does​

For a given source, destination, and optional constraints, Path Analysis returns the set of feasible paths through the modeled network and shows the per-hop forwarding, policy, and translation decisions along each one. Use it to answer:

  • Can traffic get from A to B?
  • Which devices and interfaces forward it, and in which direction?
  • Where are routing, ACL, firewall, or NAT decisions applied?
  • Why is traffic delivered, dropped, or unreachable, and which specific configuration or state entry drove that decision?

What Path Analysis Does Not Do​

  • No live traffic. Forward does not send packets or run active probes. Path Analysis is not traceroute.
  • No telemetry or flow logs. Results come from the modeled snapshot, not from observed traffic.
  • No prediction. Results reflect the network as it was when the snapshot was collected.
  • No change testing of uncollected configs. To evaluate a proposed change, apply it and collect a new snapshot.

Permit-all mode is sometimes confused with prediction, but it is not prediction. Permit-all reinterprets the same snapshot with ACLs and firewall rules treated as permits. The result distinguishes policy drops from connectivity drops. See Running Path Analysis → Permit-all mode for how to use it.

The Modeled Network​

A snapshot produces a modeled network: the devices, interfaces, links, routes, ARP and MAC entries, ACLs, NAT policies, and other configuration and state Forward collected. Path Analysis evaluates paths within that model. It cannot see devices that weren't collected, and it cannot see state that wasn't captured.

When a path needs to traverse a device Forward doesn't have, results stop at the gap and a banner flags the missing devices. See Understanding Results → Missing Devices.

Some connectivity is outside what Forward can collect directly: the public internet, leased L3 VPNs, carrier-provided WAN circuits, and encrypted transport. For those segments, you can define synthetic devices that stand in for the uncollected hop, so paths continue through them instead of dead-ending at the edge of the modeled network. Synthetic devices model user-defined connectivity. They are not a substitute for collection. If a physical device is missing from the snapshot, you still need to collect it.

Anchors and Constraints​

A query has two kinds of location clauses:

  • Anchors define where traffic enters and optionally exits the model: from() at the start of the query, to() at the end. Forward resolves anchors to specific devices and interfaces via IP localization. See IP Localization below.
  • Constraints refine which paths are included: through() and bypass() (direction-agnostic), ingress() and egress() (direction-aware, device- or interface-level). These can appear anywhere in the query and can repeat.

A query doesn't have to name both anchors. It must, however, give Forward enough information to pick a starting point. Queries with no destination anchor run broader searches and can produce large result sets that are harder to read.

See Running Path Analysis for query building, operator behavior, and common intent patterns.

important
to() vs. destination header filters

to(10.0.0.5) and ipv4_dst(10.0.0.5) look similar, but they answer different questions.

  • to(...) is an anchor. Forward runs IP localization on the argument, finds where that IP terminates in the modeled network, and includes paths that reach that device, interface, or host.
  • ipv4_dst(...) is a packet-header filter. It constrains the destination field on the sample packet, but it does not tell Forward where the path should terminate. Without a to() anchor, Forward has no target device or interface to localize, so paths run until they're delivered, dropped, or leave the modeled network.

So from(host-A) ipv4_dst(10.0.0.5), with no to(), starts at host-A with the destination IP pinned to 10.0.0.5 and follows the forwarding wherever it leads, returning whatever paths the network produces for that packet.

In short, ipv4_dst constrains the packet, and to() constrains where the path terminates.

See Running Path Analysis → IP Localization for to()'s default-lookup behavior (what happens when the IP is off-subnet, ambiguous, or hostname-resolved) and for how to disambiguate with at() or in(). See Running Path Analysis → Placement Matters for how header-filter placement (after from() vs. after to()) changes what gets constrained.

IP Localization​

When an anchor argument is a hostname, IP address, or prefix, Forward resolves it to one or more locations in the modeled network: a device, interface, or host where the IP terminates. This resolution step is called IP localization.

It draws on:

  • Interface addresses and subnet membership
  • ARP and ND tables
  • MAC address tables and Layer-2 adjacencies
  • Routing and next-hop resolution
  • Vendor-specific conventions (SVI mapping, NAT pools, etc.)

The referenced host or IP doesn't need to belong to a collected device. Forward needs only enough state from surrounding devices to place it.

When the IP could live in more than one place, narrow the scope with at() or in() (device, interface, or zone). See Running Path Analysis → IP Localization for the disambiguation rules.

The Sample Packet​

For a selected path, Forward shows a sample packet: one concrete packet that exercises that path. Each hop displays the relevant header fields and any transformations the device applies, such as NAT translation, VLAN push or pop, MPLS label operations, and MAC rewrites.

A query usually matches many packets, not just one. The sample packet is a single example drawn from that set, picked to make the path easy to read. Header fields you set in the query (like tp_dst(443)) carry through to the sample packet. Fields you leave open fall into two categories: fields covered by traffic defaults (TCP flags, app_id, and others) take their default value, while the rest (source port, TTL, and so on) take a representative value the path actually allows. If a chosen value isn't the one you want to reason about, pin it explicitly in the query or override the default. See Running Path Analysis → Traffic Defaults.

See Understanding Results → Sample Packet for how the sample packet is displayed at each hop.

Path Groups​

A single query usually matches many paths. Your anchors, filters, and modes select which of them Forward returns, and paths that traverse the same significant devices and reach the same outcome are then collapsed into a path group. The group preserves individual paths, so you can step through ECMP alternatives, underlay variations, and similar low-level differences, while keeping the top-level result set concise.

Grouping keeps the result set sized to the network's distinct forwarding behaviors rather than its raw path count, so a result stays readable even when the traffic fans out across many equal-cost or redundant paths.

See Understanding Results → Path Groups for how groups, outcomes, and significant hops are displayed.

Grounded and Ungrounded Queries​

A grounded query is anchored with a specific from source. A from location of anywhere does not count as grounded—it names no specific source, so the query is ungrounded. Grounded queries do not use advanced reachability, so they run right away, even while advanced reachability is still being computed for the Snapshot.

An ungrounded query has no specific from source — either no from clause at all (for example, to(X) on its own) or an explicit from(anywhere). To answer it, the engine has to enumerate every path that could reach the destination from anywhere in the network. That enumeration relies on advanced reachability analysis, which by default is computed on demand rather than during Snapshot processing. When you build an ungrounded query against a Snapshot that has not yet had it computed, Path Analysis recommends adding a specific from source for a faster result; you can decline and run advanced reachability instead.

See Running Path Analysis → Broad Queries for more on query shapes.

Covered Topology​

Results are overlaid on the modeled network topology. The covered topology is the union of every device and link touched by any matching path across all path groups. Devices and links not on any matching path are faded.

Use covered topology to:

  • Confirm traffic touches the parts of the network you expected, and nothing more.
  • Bound the impact area of a change by identifying which devices and links are relevant to this flow.
tip

A quick look at covered topology after each query is the easiest way to catch over-broad anchors or missing constraints.

Supported Traffic and Scope​

Traffic types​

Path Analysis models:

  • Unicast (most common) and multicast (represented as distribution trees)
  • Overlays and tunnels (VXLAN, GRE, MPLS, IPsec, etc.) with separate overlay and underlay views
  • Policy-based routing
  • Layer-7-aware policy on supported platforms, including firewall rules matching on application, service, user, or user group, and load-balancer policies steering on L7 attributes

Scope​

  • Results are bounded to a single snapshot. Cross-snapshot comparison is done via Path Diff.
  • Searches are bounded by a result cap and a timeout (default 30s, configurable up to 5 minutes). Truncated results are signaled explicitly. See Understanding Results → Incomplete Results.
  • Missing devices, parsing errors, and partial state are surfaced in the result with banners and warnings, so an empty or truncated path set caused by a gap in collection is clearly distinguished from a genuine "no path exists" answer.

Path Analysis is the foundation for several other Forward features:

  • Intent Verification: existence and isolation checks re-run on every snapshot
  • Blast Radius: reachable destinations from a source IP, prefix, or endpoint
  • Security Posture: allowed, denied, and conditional reachability between zones or endpoint groups

Next​