Prediction Scope
This page defines the scope of a prediction: the change types Forward Predict supports, the routing protocols it re-propagates, and the platforms it re-models in full. Confirm a scenario against this page before building it.
Change Types
The device editor offers two ways to specify a config change: a Modify using: control with the options CLI commands
and Config file. Firewall rule edits and BGP advertisements are separate change types.
| Change type | What it means | Scope |
|---|---|---|
| CLI commands | Vendor-native config lines merged into the device's current config. | Command-merge OS families (see Config Prediction Across Vendors). |
| Config file | A complete running config that replaces the device's baseline config. | Accepted for any device Forward Predict can parse. What the prediction shows is bounded by platform support; a re-synthesized routing table needs a supported platform. |
| Firewall rule change | Add, delete, edit, and reorder security rules through a graphical editor. | Palo Alto (PAN-OS) firewalls only. Other platforms use a config-based change. |
| BGP advertisement (inject) | Model an external peer advertising a prefix, with full path attributes. | Answers "what if my provider sends me this prefix?" |
| BGP advertisement (withdraw) | Model a prefix being withdrawn from a peer. | Failure and de-peering scenarios. |
One change set can combine these across multiple devices and commit them as a single scenario. Preview the resulting config with Preview config changes, then commit with Save changes & continue.
Changes Predict Does Not Model
- Topology changes. Forward Predict cannot add or remove a device or link, or model a link going down.
- Interface-state, IP, VLAN, and VRF-membership changes. Shutting an interface, changing an interface address, or moving an interface between VLANs or VRFs are not supported change types in the current version.
- L2 control-plane reconvergence. Forward Predict does not re-compute spanning tree or first-hop redundancy (HSRP, VRRP) across devices.
On a changed device, Forward Predict rebuilds the device's full local model from the new config. ACL, NAT, and security-policy edits take effect there: traffic that traverses the device is filtered and translated as the new config dictates, and end-to-end reachability through the device reflects the change.
Across the topology, routing is the only thing Forward Predict re-propagates. A change to the routes a device originates or forwards reaches other devices through that propagation. An ACL, NAT, or security-policy edit stays local to the device it is applied on, because a network device enforces those locally rather than advertising them to its neighbors. See the list above and How Predict Works for the network-wide behaviors it does not recompute.
Supported Routing Protocols
In 26.9, Forward Predict re-propagates BGP across the network. Support for the other protocols below is planned for later releases.
| Protocol | 26.9 status |
|---|---|
| BGP | Re-propagated. IPv4 and IPv6 unicast, VPNv4/VPNv6 (L3VPN), and IPv4 labeled unicast (BGP-LU). Not modeled: EVPN, VPLS, multicast and MVPN, BGP-LS, SR policy, and flowspec. |
| Cross-protocol redistribution | Into BGP only. A route redistributed into BGP re-propagates within the BGP domain. Redistribution into another protocol is not re-propagated. |
| OSPF | Not re-propagated; planned for a later release. When available: OSPFv2 and OSPFv3 (IPv4 and IPv6), with Segment Routing over OSPF (SR-MPLS, prefix and adjacency SIDs) not modeled. |
| Static and connected routes | Not re-propagated; planned for a later release. |
| SD-WAN overlay (OMP) | Not re-propagated; planned for a later release. |
| IS-IS, EIGRP, RIP | Not re-propagated; planned to follow. |
A route that another protocol redistributes into BGP re-propagates within the BGP domain. A change that must travel through a protocol Forward Predict does not yet re-propagate does not reach devices beyond that boundary. For example, an EIGRP route already redistributed into BGP re-propagates as a BGP route, but editing the EIGRP configuration that would add or drop that route has no effect, because Forward Predict does not re-compute EIGRP. Confirm which protocol carries the traffic in scope before relying on a prediction.
Cross-Protocol Route Selection
When more than one protocol offers a route to the same prefix on a device, Forward Predict picks the winner by
administrative distance (route preference on Juniper), using each platform's own defaults and any values configured on
the device. It models these defaults per vendor, so they differ where the real platforms differ: eBGP is 20 on Cisco,
170 on Juniper, and 200 on Arista. Configured overrides (distance bgp, distance ospf, and Juniper preference) take
precedence over the defaults.
Supported Platforms
A routing change produces a fully re-synthesized routing table only on devices running one of these platforms:
- Cisco IOS, IOS-XE, IOS-XR, NX-OS, and NX-OS (ACI)
- Cisco ASA
- Juniper Junos and SRX
- Arista EOS
- Fortinet
- Palo Alto PAN-OS
MPLS forwarding-state synthesis is supported on a subset of this list: Cisco IOS-XE, IOS-XR, and NX-OS.
Forward Predict includes a device on any other platform in the model and in analysis but does not re-synthesize its routing state. When a change on a supported device (say, Cisco IOS-XE) recomputes routes that propagate across the network and reach such a device:
- Its routing table in the predicted snapshot stays exactly as collected, even where the change would alter what it learns.
- The routes do not propagate through it to its neighbors; re-propagation stops at that device.
- A predicted path that traverses it forwards on its collected routing, not on any reaction to the change.
Confirm the changed device and every device the routes pass through all run one of the platforms above. An unsupported device along the way stops the change from reaching anything beyond it.
Config Prediction Across Vendors
Forward Predict computes the resulting config with vendor-aware logic, not a naive text append. The two config change types differ in scope.
- Config file supplies a complete running config that replaces the device's baseline. Forward Predict re-parses and
re-models the device from it. Its reach depends on the platform:
- It accepts a config file for any device it can parse.
- The prediction reflects only what it models for that platform. A device outside the supported platforms participates in the model but gets no re-synthesized routing table.
- Behavior it does not model for that platform is not predicted, even when the pasted config changes it.
- Routing is the common case: on an unsupported platform, a config change that would alter the device's routing table or routing state, whether the effect stays local or propagates to other devices, is not modeled. The device's collected routing state carries into the predicted snapshot unchanged.
- CLI commands are merged into the device's current running config the way that vendor's CLI would apply them, so the predicted config matches what the commands would produce on the device. Command-merge is supported on eight OS families:
| Vendor | OS families |
|---|---|
| Cisco | IOS-XE, IOS, NX-OS, IOS-XR, ASA |
| Arista | EOS |
| Juniper | Junos, SRX |
For a device outside these eight, use the Config file option to supply a full replacement config. The previewed config diff reflects how the device would actually apply the change.
Accuracy and Limitations
Within the scope and properties on this page, Forward Predict computes a result exactly from the model's inputs. Even so, a few things keep a prediction from always matching the live network:
- It's a model, not a promise. A prediction shows how the network should behave, not a certainty that every detail matches the live network.
- Software has bugs and gaps. Like any software, Forward Predict can have a bug, and some cases aren't modeled yet. Either can make a prediction wrong.
- Some choices aren't deterministic. When several equally good paths exist, a device picks one by its own internal rules, often ones the vendor doesn't publish (for example, whichever route arrives first). Forward Predict picks one of them, or several if the device uses multipath, but it can't promise which path a given packet will actually take. See How Predict Works → Accuracy Boundaries.
- A snapshot can go stale. A prediction is based on the last collected snapshot. If the network has changed since, the prediction can be off; re-collect and predict against a current snapshot.
- It won't catch every risk. Use Forward Predict to check a change before you make it, not as a promise that the change is safe to deploy.
Next
- How Predict Works: the modeling and propagation behind a result.
- Firewall Predict: the Palo Alto security-rule workflow in detail.