Skip to main content

Reference

This page is the lookup for each synthetic-device type: what it models, how it routes, and the fields and constraints on its connections. The task pages cover the rest: Choosing a Device to pick a type, Configuring Connections to set connection fields, and Automated Setup with NQE to generate connections in bulk.

All synthetic devices can be configured through the REST API. The full endpoint reference is the Synthetic Devices API; this page describes behavior, not request bodies.

Device Types​

Internet node​

Represents the public internet or third-party public IP infrastructure. Use it to trace paths between sites connected over the internet.

  • Routes public addresses only. Private and reserved addresses (RFC 1918 and the broader reserved ranges) are not routed by the internet node and are rejected if you list them in its subnets or exclusions.
  • Owns unassigned public space. Any public subnet not located at a connected site is located at the internet node, on a port named self.
  • One per network, edited from its own drawer. Every network shows an internet node on the Sources page, edited from its own drawer rather than the Add synthetic device wizard. You can't delete or rename it; its name is always internet. It stays inert until it has connections, and joins the model only after Forward collects cloud devices and auto-connects it (see below) or you give it a connection.
  • Auto-connects to cloud objects. Forward connects the internet node to internet-facing cloud objects (AWS, Azure, GCP, IBM Cloud, Alkira) automatically, deriving the public addresses from the cloud object's routing and NAT rules.
  • Exclude public subnets. You can list public subnets to keep from being located at the internet node (for example, public space you route internally). Each entry must be a valid CIDR block. Excluded subnets are removed from what the internet node owns, so they localize to your internal devices instead.

Connections use the shared L3 fields. Edited via its own drawer on the Sources page, not the Add synthetic device wizard.

Intranet node​

The internet node's counterpart for a private inter-site network, such as a leased L3 service or an L3 hub-and-spoke where the intranet node is the hub.

  • Routes public and private addresses.
  • Does not own unassigned public space. Unlike the internet node, public addresses not belonging to a connected site are not located at an intranet node. You model only the sites you connect.
  • Multiple allowed, user-named. A snapshot can contain several intranet nodes.

Connections use the shared L3 fields. Added via the Add synthetic device wizard.

Adjacent network​

Models an external network you connect to but don't manage — a partner network, a counterparty bank, a payment network — that your traffic reaches and returns from but never routes through. It's a traffic sink: a valid path source and destination, but never a transit hop.

  • Never transits. Traffic arriving on one connection is delivered to the adjacent network itself, not forwarded out another connection. This is the one behavioral difference from the intranet node and L3 VPN, which route between connections. Use it for a network that terminates your traffic (a partner you send to and receive from), not one that carries your traffic between your own sites.
  • Owned subnets. You list the subnets the adjacent network owns; Forward locates them at the node, so they resolve as a path source or destination. This is what makes the partner network addressable. Owned subnets differ from a connection's advertised subnets: owned subnets sit at the node, while advertised subnets are reachable across the connection toward the gateway.
  • Works as a path endpoint. Like the internet and intranet nodes, it has a self interface, so its addresses originate and terminate traffic — you can use it as a path source or destination, and as a Blast Radius source.
  • Models L3 reachability only. It's a routing model, not a tunnel: it doesn't encapsulate traffic or model a VPN. For an IPSEC tunnel use an Encryptor; for a provider L3 VPN / MPLS core use an L3 VPN.
  • Multi-homed. Multiple uplink connections to one or more collected devices, so you model every link to the partner from every location in one device.
  • Multiple allowed, user-named. A snapshot can contain several adjacent networks.
  • No VRF. Like the internet node, adjacent-network connections have no VRF field; all connections share one routing domain. It otherwise uses the shared L3 fields and all four subnet auto-discovery modes.

Added via the Add synthetic device wizard. Its edit form has a Connections tab and an Owned subnets tab, where you enter the owned subnets one CIDR block or address per line.

note

Available in release 26.8 and later.

L2 VPN​

Models a provider L2 VPN service that extends one L2 broadcast domain across the WAN. It acts as a distributed virtual bridge that brings all access circuits into a single broadcast domain (one VSI, in RFC 4664 terms).

  • Connections are customer-edge interfaces, each with an optional VLAN and connection name. Two or more connections form the broadcast domain. No gateway, subnet discovery, or backdoor fields.

Added via the Add synthetic device wizard.

L3 VPN​

Models a provider L3 VPN / MPLS network without collecting the provider's PE and P routers. The devices you connect are customer-edge (CE) routers.

  • Each CE advertises the subnets it owns. Forward determines them per connection through subnet auto-discovery — from CE BGP, from the RIB, from the gateway interface addresses, or entered manually. When another CE's connection advertises a subnet, Forward models a route across the VPN to that CE; traffic to subnets no CE advertised is dropped.
  • Connections are VRF-aware. Each connection names the VRF whose routing domain the connection joins.
  • Connections otherwise use the shared L3 fields.

Added via the Add synthetic device wizard. Uses BGP advertisement collection when a connection is set to From BGP routes discovery.

WAN Circuit​

Models a point-to-point Layer-2 link through a provider: a bridge with a different VLAN allowed on each side.

  • Exactly two connections (connection1 and connection2), one per end. Each is a LAN interface with an optional VLAN and connection name. There's no separate add/remove-connection step; you define both ends together.

Added via the Add synthetic device wizard.

Encryptor​

Models a device that encapsulates traffic in an IPSEC tunnel.

  • Has a site connection, an optional underlay connection, one or more tunnels (each a source/destination pair), and the subnets carried over the tunnel.
  • Configured through the REST API (Encryptors API).

Where Synthetic Devices Are Located​

Synthetic devices are placed automatically in every location where they have a connection; you can't assign a specific location (the API rejects a location field). This applies to the internet node, intranet nodes, adjacent networks, L2 VPNs, L3 VPNs, WAN circuits, and encryptors.

Two types are anchored to a fixed location instead: the auto-generated Missing Peer and synthetic optical devices.

Automatic placement applies to releases 25.10 and later.

L3 Connection Fields​

The fields on an L3 connection (Internet node, Intranet node, Adjacent network, L3 VPN). For how to set each, see Configuring Connections.

FieldRequiredWhat it sets
Uplink interfaceYesThe collected device and interface that connects to the synthetic device.
Gateway interfaceNoThe last L3 interface that routes toward the synthetic device. Defaults to the uplink interface (with its VLAN); need not be on the same device as the uplink.
VLANNoOn-wire VLAN of traffic leaving the uplink. Blank for untagged. Taken from the encapsulation on a dot1q subinterface.
VRFNoNot on the internet node or adjacent network. The VRF the connection's traffic belongs to; connections interconnect only within the same VRF. Blank means the default VRF. Central to the L3 VPN.
SiteNoGroups gateways that reach the same segment, so Forward doesn't model a loop across the synthetic device.
Connection nameNoCustom name for the interface created on the synthetic device. Auto-generated from the VRF, uplink port, and VLAN if blank.
Subnet auto-discoveryYesHow connection subnets are found: Off, From IP routes, From BGP routes, or Use interface addresses (see below).
SubnetsWith OffThe subnets reachable across the connection. Required and non-empty when auto-discovery is Off; otherwise inferred.
Peer IPsNoFrom BGP routes only. Restricts discovery to subnets advertised to these eBGP neighbors.
Advertises default routeNoFrom IP routes only. When set, a default route (0.0.0.0/0) the gateway forwards out a non-uplink port is counted as advertised. Off by default, because an unverified default route can blow up path counts.
Backdoor portsNoPorts whose forwarded subnets are subtracted from the discovered set, so the gateway isn't modeled as a transit hop for them.

L2 VPN and WAN Circuit connections have only an interface, an optional VLAN, and an optional connection name; they don't route, so they have none of the gateway, VRF, site, discovery, or backdoor fields.

Subnet Auto-Discovery Modes​

Available on L3 connections (Internet node, Intranet node, Adjacent network, L3 VPN). See Configuring Connections → Subnet Auto-Discovery for guidance.

ModeInferred subnets
OffNone. Subnets must be listed manually (non-empty).
From IP routesSubnets the gateway forwards out a non-gateway, non-self port. Excludes the default route, gateway-directed routes, and backdoor subnets.
From BGP routesSubnets the gateway advertises via eBGP (Adj-RIB-Out, post-policy); restrictable to specific peers.
Use interface addressesOnly the gateway interface's own addresses.

For the internet node, private and reserved addresses are excluded from every mode.

Fallback: a connection set to From BGP routes falls back to From IP routes if eBGP advertisements weren't collected on the gateway device.

BGP Advertisement Collection​

L3 VPNs, Internet nodes, Intranet nodes, and Adjacent networks can model routing more accurately using each device's BGP advertised routes (Adj-RIB-Out, post-policy) in addition to its RIB. Forward enables this collection automatically for a device when you connect it to one of these synthetic devices with From BGP routes discovery.

An adjacent-network gateway needs more: because the adjacent network also locates the subnets the partner advertises to you, its From BGP routes gateways collect both received (Adj-RIB-In) and advertised (Adj-RIB-Out) routes, where an internet-node, intranet-node, or L3 VPN gateway collects only advertised routes. Forward sets this per gateway automatically.

Restrictions:

  • The PE-CE protocol must be eBGP. Other dynamic protocols and static routing fall back to the standard model, where only the RIB is used (no routing policy or filters).
  • Support depends on platform. See the Feature Matrix for the current list.

BGP advertisements are collected via the device CLI by default; the collector also supports collection via BGP Monitoring Protocol (BMP). See BGP Collection for per-device settings and Collecting With BMP.

Include all CE routers in the snapshot before creating the synthetic devices that depend on them. A connection to a device that isn't in the snapshot fails silently: it passes validation and saves, but on processing it's dropped, leaves a down interface on the synthetic device, and contributes no routes. Traffic to the absent CE's subnets is then dropped at the L3 VPN as unadvertised, the same as any prefix no site advertises.

REST API​

Every synthetic-device type is configurable through the REST API, including endpoints to add and remove connections and to compute NQE-based connections. For endpoints, request bodies, and examples, see the Synthetic Devices API.