What-if simulation
What-if answers one question: if I make this change, what stops working and what starts? You describe a security-rule or NAT change without making it, and every flow is traced twice — once against the config as it stands, once against the config with your change applied. Anything that answers differently is listed, with the full before and after path. Nothing touches the device until you press Apply to config.
Where the flows come from#
Three sources, merged and de-duplicated:
- Your probes — a source IP, a destination IP, a protocol and a port. These are the questions the report can always answer, and the ones to use when a change request names a specific flow.
- The design's own subnets — representative flows derived from addressed SVIs and the VLAN database.
- The staged rule itself — its source and destination addresses crossed with its services.
any, or a design whose subnets have no IPs yet, produces nothing to trace. When that happens the step says “Nothing was probed, so nothing was proved” rather than reporting the change as safe — absence of evidence is not evidence of absence, and a change-review tool that confuses the two is worse than none.Reading the verdicts#
| Breaks | The flow worked before your change and is blocked after. The one to look at first. |
| New access | Blocked before, works after. Intended for an allow rule — worth a second look on anything else. |
| Rerouted | Still reachable, but the path through the network changed (a NAT change often does this). |
| Unchanged | Same verdict both ways. |
Two results deserve attention even though they show no changed flows. “Already handled by an existing rule” means the rule you staged is shadowed by one above it — the classic “I added the rule and nothing happened”. “None of the probed flows pass through this firewall” means the probes are asking about a part of the network this box isn't in, so its rules could not have changed them.
A worked example#
A change request asks you to remove a permissive outbound rule. Stage Security rule → Delete, pick the rule, add one probe for the flow the application team cares about (10.1.2.3 → 10.9.8.7:1433), and simulate. If the report comes back with that probe under Breaks, the rule is load-bearing and the request needs a narrower replacement first. If it comes back unchanged and the design-wide probes are unchanged too, you have evidence to attach to the ticket — Copy report for change ticket produces the plain-text before/after summary for exactly that.
What it does not model#
Flows are representative, not exhaustive: a clean result means the flows tested did not change, not that nothing anywhere did. Traffic is evaluated against zones, addresses, services, routing and NAT. It does not model session state, application-layer inspection, threat or URL profiles, or per-rule schedules. Treat it as a fast, checkable first pass — not as a replacement for a maintenance window.