Networking

Plan four kinds of connectivity before deploying: site-to-site bandwidth for replication, inter-node communication, outbound access to platform APIs, and (optionally) reachability of recovered instances for post-recovery scripts.

Bandwidth

Replication time is a direct function of changed-data volume and available bandwidth between the sites.

Under-provisioned bandwidth does not break replication — changed data eventually syncs for all protected applications — but it stretches replication time and can cause the configured RPO of a protection plan to be missed. If you need to cap usage during business hours, use bandwidth throttling: per-node limits and time-windowed limits are both supported.

Inter-node connectivity

Connectivity between Datamotive nodes, within and across sites, carries metadata and protected VM data. All transfers are secured, and encrypted transfer on the wire can be enabled per protection plan. The traffic can run over private subnets or secured VPN tunnels depending on your network and security design.

The exact port matrix is in the Ports reference. Create one security group per node type as described in Firewall.

Outbound connectivity to platform managers

To orchestrate DR and migration workflows, nodes call the platform manager APIs — vCenter Server for VMware, and the public API endpoints for AWS, Azure, and GCP. Operations include creating VMs, creating subnets, and fetching security groups.

• For cloud platforms, the API endpoints are reached over the internet, so nodes need outbound internet connectivity (port 443).
• No organization data is transmitted over this connection — it carries orchestration calls only.

Connectivity with recovered entities

If you configure custom pre- or post-recovery scripts that reconfigure recovered instances (for example DNS updates inside the guest), the Datamotive nodes executing those scripts need network connectivity to the recovered instances. If you do not use such scripts, this path is not required.

Hostname resolution

Each node's local hostname must resolve correctly — through DNS or /etc/hosts. Verify with a ping <hostname> from inside the node. DNS for vCenter/ESXi hostnames (VMware) and cloud API endpoints (AWS/Azure/GCP) must also be available; see Firewall — DNS requirements.

Static IP addressing

Configure static IPs on all Datamotive nodes so addresses cannot change during DR operations — DHCP is only acceptable for first boot. Cloud nodes should use private IPs (or reserved/Elastic IPs when public access is required); VMware nodes are configured via netplan. Full procedure and netplan examples: Firewall — IP configuration.

Related docs

• Ports

• Firewall

• Preparing target site

• Replication configuration