Reachability Verification

Reachability is the strictest of the three Intent Verification types. Where Existence asks "does some matching path exist?", Reachability asks "does every matching packet at network ingress get delivered, and only to its intended destination?"

This page describes how Reachability checks evaluate traffic, the rules the query must follow, and worked examples of checks that pass, fail, and are rejected at save time.

Pass conditions

The from clause of a Reachability query defines a region of the packet header space at network ingress — the header filters you specify (source/destination IPs, L4 ports, VLANs, and so on) together with an optional location filter (interface, device, security zone, or subnet). Any header field you don't specify is wildcarded — it matches every valid value. For example, a from clause with only ipv4_src.10.0.0.0/24 and tcp_dst.443 describes packets from any source port, any VLAN, any DSCP, and so on, as long as the source IP and destination port match.

The check passes when both of the following hold across that entire region:

1. No packet in the region fails delivery. No sub-region of the from space is dropped, blackholed, or caught in a forwarding loop; every packet described by from exits the network through some edge port.
2. No packet in the region is delivered to the wrong place. If the query has a to clause, the delivery location for every packet in the from region must match to. No packet may land anywhere else.

If the query has no to clause, only condition 1 is evaluated — traffic must be delivered, but the delivery location is not validated.

The platform evaluates these conditions symbolically using header-space analysis. It does not enumerate individual packets; it intersects the from region with the network's forwarding behavior and looks for any non-empty sub-region that violates a condition. When the check fails, the violation report contains one representative violating flow. If the query has a to clause, the diagnosis also includes a companion entry for the other failure condition (delivery-to-wrong-place vs. undelivered) so the GUI can surface it alongside the primary violation; that companion entry may or may not itself contain matching flows.

Rules for the to clause

For a Reachability check, the to clause specifies only a location — an interface, device, security zone, or subnet. Header filters on to (source or destination IPs, L4 ports, protocols, VLANs) are not permitted and the check is rejected with a validation error at save time.

What "location" means here

"Location" refers to a logical position in the modeled network — a specific interface, device, security zone, or subnet — not a geographic or topology-diagram position. The platform resolves it to the concrete device and interface via IP localization at evaluation time. See Anchors and IP Localization (Anchor Resolution) for the full treatment.

For example, the following query is valid for a Reachability check — from carries all the header filters and the destination IP, and to specifies only the egress device:

from(10.0.0.0/24)(ipv4_dst.10.20.30.40)(tcp_dst.443) to(appA-server)

The same query with an extra header filter on to is rejected:

from(10.0.0.0/24)(tcp_dst.443) to(appA-server)(ipv4_dst.10.20.30.40)
                               ↑ not allowed on a Reachability check

This differs from Existence and Isolation checks, where to may carry both a location and header filters.

To constrain the check to specific destination IPs, put them on the from side (see Specifying destination IP addresses). The to clause is then used purely to constrain where the traffic is allowed to land.

The from location filter accepts the same types as to — including interfaces, devices, security zones, and subnets — so an interface-level ingress can be described directly on from.

Specifying destination IP addresses

Destination IPs always live on the from side of a Reachability query, because from describes the packet as it enters the network.

• GUI wizard: put destination IPs, ports, and protocols into the destination-side fields under from.
• REST API: use header-field names like ipv4_dst or tcp_dst for concrete values. When referencing a named alias, set direction: "dst" on the PacketAliasFilter.

Values are pre-translation. If traffic traverses a NAT or load balancer, use the pre-NAT destination (for example, the application VIP, not the real backend IP).

Clauses not supported in Reachability queries

Some refinement clauses are incompatible with the Reachability semantics and are rejected at save time:

• Bypass filters
• Flow-type filters

Scoping the from region carefully

Because unspecified header fields are wildcarded, a from clause narrower than it looks on paper can still cover a very large region of the header space. Any sub-region the network legitimately drops — for example, ingress packets with an unexpected VLAN tag or a protocol that isn't supposed to arrive on that port — will be reported as a violation.

When a legitimate drop is being flagged, constrain from so it no longer covers that sub-region: add the expected VLAN, protocol, or port range so the query describes only the traffic that is supposed to be delivered. See Example 4 for a worked case.

Reachability vs. Existence

Consider a check that verifies user subnet 10.0.0.0/24 can reach application appA over TCP port 443.

• Existence passes if at least one packet from 10.0.0.0/24 to appA:443 is delivered. A single valid path is enough, even if other packets in the same set are dropped or misrouted.
• Reachability passes only if every packet in 10.0.0.0/24 → appA:443 is delivered, and — when a to clause is set — each one lands at appA's location.

Reachability therefore catches partial outages and asymmetric-routing issues that Existence cannot.

Worked examples

The following five examples cover the common outcomes: two that pass, two that fail at evaluation time, and one that is rejected at save time as invalid.

Example 1: Valid, passes — user subnet to a file server

from(10.20.0.0/24)(ipv4_dst.10.40.5.10)(tcp_dst.445) to(file-srv-01)

How to read it. The from clause defines the ingress region: any source IP in the user subnet 10.20.0.0/24, any source TCP port, destination IP 10.40.5.10, destination port TCP/445 (SMB). Every other header field (VLAN, DSCP, IP protocol beyond TCP, and so on) is wildcarded. The to clause is location-only — the host file-srv-01 — stating that traffic must land there.

Why it passes. For every sub-region of the from space, the network's forwarding graph delivers the packet to file-srv-01 and nowhere else. No drop, no loop, no misroute.

What the user sees. Check result: Pass. No diagnosis details.

Example 2: Valid, fails — one rack has the wrong ACL

from(10.20.0.0/24)(ipv4_dst.10.40.5.10)(tcp_dst.445) to(file-srv-01)

Same query as Example 1, different snapshot: an ACL was recently tightened on the leaf switch serving rack 10.20.0.128/25 and now drops SMB.

How to read it. Identical query semantics. The from region is the same, but the forwarding behavior has changed inside the snapshot.

Why it fails. Header-space analysis intersects from with the ACL and finds a non-empty sub-region (10.20.0.128/25 → 10.40.5.10:445) that is now dropped. The rest of from still passes.

What the user sees. Check result: Fail. Diagnosis shows one representative flow — for example, a single path from 10.20.0.200 → 10.40.5.10:445 ending in a drop at leaf-02's ACL acl_smb_deny.

Example 3: Valid, fails — traffic is reaching the wrong zone

from(10.50.0.0/24)(ipv4_dst.10.60.0.0/24) to(prod-zone)

How to read it. Ingress is the user subnet 10.50.0.0/24 with destinations in the /24 block that is supposed to hold only production servers. to(prod-zone) says the traffic may only land inside the prod-zone security zone — nowhere else.

Why it fails. A subset of the destination /24 — say 10.60.0.240–255 — was recently re-homed into the dev-zone. Reachability's second pass condition (no packet may land outside to) catches this: a sub-region of from is delivered, but to a location that does not match prod-zone.

What the user sees. Check result: Fail. Diagnosis shows a representative flow delivered into dev-zone instead of prod-zone, pointing at the specific leaf interface and SVI where the packet exits. This is the class of issue Existence checks cannot catch — an Existence check would pass because some traffic does reach prod-zone.

Example 4: Valid, fails — from is too broad and catches legitimate drops

from(access-port-eth1/3) to(voip-gateway)

How to read it. from specifies only an ingress location — a single access port — with no header filters. That region is enormous: every possible header that could arrive on that port, including VLANs the port isn't trunking, broadcast/multicast frames, ARP for unknown neighbors, and so on. to requires every packet to end up at the VoIP gateway.

Why it fails. The port is in VLAN 20; frames tagged with other VLANs are legitimately dropped by ingress classification. Reachability intersects the wildcarded from region with forwarding and flags the dropped sub-region as a violation, even though the drop is intentional network policy.

What the user sees. Check result: Fail. Diagnosis shows a representative violating flow — for example, a VLAN-30-tagged packet dropped at ingress on access-port-eth1/3.

How to fix it. Tighten from so it describes only the traffic the policy is about:

from(access-port-eth1/3)(vlan_vid.20)(ip_proto.UDP)(udp_dst.5060) to(voip-gateway)

The failing sub-region is no longer inside from, so the check passes.

Example 5: Invalid — rejected at save time because to carries a header filter

from(10.0.0.0/24)(tcp_dst.443) to(webapp-server)(ipv4_dst.10.99.1.1)

How to read it. The author tried to constrain both the egress location (webapp-server) and a destination IP on the to side.

Why it's invalid. Reachability's to clause accepts a location only. The platform rejects the query at save time with:

'to' header filters not allowed in Reachability check

What the user sees. A validation error in the wizard or a 400 response from the API — the check is never created and never runs.

How to fix it. Move the destination IP to the from side (where header filters belong for a Reachability check):

from(10.0.0.0/24)(ipv4_dst.10.99.1.1)(tcp_dst.443) to(webapp-server)

Now from fully specifies the packet set, and to constrains only where it must land.