Traffic classes¶
Everything in Firevyzer is built on traffic classes. Understand this one idea and the three workflows follow directly.
The idea¶
A traffic class is a concise, symbolic set of packets — one description that stands in for countless individual flows. Instead of reasoning packet by packet, Firevyzer partitions the entire packet space into a handful of classes and reasons about those.
Two properties make this useful:
- Complete — the classes partition the whole packet space. Every possible flow falls into exactly one class, so an analysis over the classes is an analysis over every flow. Nothing is sampled; nothing is missed.
- Concise — a single class can describe an unbounded set of packets, including "negative" shapes like every port except 22.
Why this matters
Completeness is what separates Firevyzer from spot-checking. A test that
asks "can 10.2.0.4 reach :443?" only tells you about the packet you
thought to send. A partition into traffic classes tells you about all of
them at once.
How a class is described¶
A class has a structured match — a per-field map. Only the fields that are
constrained appear; an absent field means any for that dimension.
| Field | Meaning | Renders as |
|---|---|---|
srcip, dstip |
source / destination address | a dotted IP or CIDR string |
proto |
protocol | a name resolved from its IANA number |
srcpt, dstpt |
source / destination port | a value list or an exclusion set |
For proto, srcpt, and dstpt, the value is an object {op, values}:
op: "eq"— the field is one ofvalues.op: "neq"— the field is anything exceptvalues. This is what renders as "any except 22" (addresses) or "not 22" (ports).
Protocol values are IANA protocol numbers as strings: 6 = TCP, 17 =
UDP, 1 = ICMP.
{
"description": "proto=tcp * -> 10.0.0.2:!{22}",
"match": {
"dstip": "10.0.0.2",
"proto": { "op": "eq", "values": ["6"] },
"dstpt": { "op": "neq", "values": ["22"] }
},
"exact": true
}
That class reads: TCP, from anywhere, to 10.0.0.2, on any port except 22.
Firevyzer renders strictly from the structured match — the description
string is a convenience only.
exact is always true
Every class Firevyzer emits is exact: correlated sets are split into multiple exact classes rather than approximated. A class never over- or under-claims the packets it covers.
Rules that decide classes¶
When a class is the result of an analysis, Firevyzer attaches the rule responsible as a rule reference:
index— the rule's 0-based position in the policy.index: -1— the implicit default-deny at the bottom of every ACL.action— allow or drop.label— the rule's comment or name, if it has one.
This is the thread that runs through every workflow: a class of traffic, and the exact rule that decides it.
Where classes show up¶
The same primitive powers all three workflows: