All Testground runners except for the local:exec runner have two networks: a control and a data network.

  • Test plan instances communicate with each other over the datanetwork.

  • Test plan instances communicate with infrastructure services such as the sync service and InfluxDB over the control network.

This separation allows test instances to simulate disconnected scenarios; intermittent, failing connectivity; or high-latency scenarios without affecting other infrastructural comms.

The local:exec runner will use your machine's local network interfaces.

For now, this runner doesn't support traffic shaping.

Control Network

The control network is used to be communicate with Testground services, such as the sync service or InfluxDB. You don't need to do anything special to configure or use this network: the sidecar will do it for you automatically.

After the sidecar is finished initializing the network, it should be impossible to use the control network to communicate with other test plan instances.

However, a good test plan should avoid listening on and/or announcing the control network anyways to ensure that it doesn't interfere with the test. Your test plan should always communicate with other test instances via the data network.

Data Network

The data network, used for communication between test plan instances, will be assigned a B block in the IP range Given the B block X.Y.0.0, X.Y.0.1 is always the gateway and shouldn't be used by the test.

The subnet used will be passed to the test instance via the runtime environment (as TestSubnet).

From the Go SDK, you can use the network.GetDataNetworkIP() function to acquire your data network IP address.