Trace by traffic class¶
Question this answers: "What happens to everything destined for this host or subnet?"
Pin a class of traffic — a host, a subnet, a protocol, a port — and watch how the policy actually handles it. Firevyzer splits that traffic into allow / drop segments end to end, names the deciding rule for each, and surfaces the rules that are pre-empted along the way.
Defining a scope¶
The scope controls take a partial traffic match — any combination of:
| Field | Accepts |
|---|---|
| Protocol | any, tcp, udp, icmp |
| Source | an IP, a CIDR, or blank for any |
| Destination | an IP, a CIDR, or blank for any |
| Dest port | a port, range, comma list, or blank for any |
This scope does double duty. As a trace, it decomposes the queried traffic into exactly how the policy treats it. As a focus, the same class narrows every other panel — Changes and Health specialize to just these packets. Leave every field blank to analyze all flows (the default).
Reading a trace¶
The result is an exact input→output decomposition: a set of disjoint segments that union to exactly the traffic you queried. Each segment names the rule that decides that slice and the resulting verdict.
Tracing TCP to a host
Query tcp → 10.0.0.5 against a policy that allows :22, drops the rest to
.5, then broadly allows TCP elsewhere:
allow tcp · any → 10.0.0.5 : 22 by rule 0 · allow
drop tcp · any → 10.0.0.5 : not 22 by rule 1 · drop
Two segments, disjoint, together covering all TCP to .5 — port 22 allowed,
everything else dropped.
Pre-empted rules¶
A trace also reports shadowed rules: rules whose guard matches the queried flow but that decide none of it, because an earlier rule got there first. Each comes with the verdict it would have applied:
would allow rule 2 · allow matched tcp · any → 10.0.0.5
would drop rule 3 · drop matched tcp · any → 10.0.0.5
This is how you catch a rule that looks like it governs a host but is entirely pre-empted — a frequent source of "but I have a rule for that" confusion.
Segments vs. guards
A segment reflects what a rule actually decides in context — its
decision region once every rule above it has had first claim — not the
rule's written guard. A "drop all TCP to .5" rule sitting under "allow TCP
.5:22" decides tcp → 10.0.0.5 : not 22, not all of .5.
The result shape¶
For integrators, a trace returns segments and shadowed:
{
"segments": [
{ "rule": { "index": 0, "action": "allow" }, "verdict": "allow",
"traffic": [ { "description": "proto=tcp * -> 10.0.0.5:22" } ] },
{ "rule": { "index": 1, "action": "drop" }, "verdict": "drop",
"traffic": [ { "description": "proto=tcp * -> 10.0.0.5:!{22}" } ] }
],
"shadowed": [
{ "rule": { "index": 2, "action": "allow" }, "would_be": "allow",
"matched": [ { "description": "proto=tcp * -> 10.0.0.5" } ] }
]
}