> For the complete documentation index, see [llms.txt](https://protocol-labs.gitbook.io/testground/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://protocol-labs.gitbook.io/testground/table-of-contents/concepts-and-architecture/networking.md).

# Networking

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 `data`network.
* Test plan instances communicate with infrastructure services such as the [sync service](/testground/table-of-contents/concepts-and-architecture/sync-service.md) 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 communicate with Testground services, such as the [sync service](/testground/table-of-contents/concepts-and-architecture/sync-service.md) or InfluxDB. You don't need to do anything special to configure or use this network: the [sidecar](/testground/table-of-contents/concepts-and-architecture/sidecar.md) will do it for you automatically.

After the [sidecar](/testground/table-of-contents/concepts-and-architecture/sidecar.md) 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 `16.0.0.0/4`. 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`).

?> **Success** From the Go SDK, you can use the [`network.GetDataNetworkIP()`](https://pkg.go.dev/github.com/testground/sdk-go@v0.2.1/network?tab=doc#Client.GetDataNetworkIP) function to acquire your data network IP address.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://protocol-labs.gitbook.io/testground/table-of-contents/concepts-and-architecture/networking.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.