Configuring container-to-container networking

The container-to-container networking feature, also known as CF Networking, allows direct network traffic between apps. For an overview of how container-to-container networking works, see Container-to-container networking.

Important Container-to-container networking is not available for apps hosted on Microsoft Windows.

Container-to-container networking enables VMware Tanzu Application Service for VMs (TAS for VMs) to generate logs whenever containers communicate or attempt to communicate with each other. For more information about managing app traffic logging, see the App Traffic Logging section of the Configuring Logging in TAS for VMs topic.

Configure the Overlay Network

Container-to-container networking uses an overlay network to manage communication between app instances. By default, each Diego Cell in the overlay network is allocated a /24 range that supports 254 containers per Diego Cell, one container for each of the usable IP addresses, .1 through .254. For more information about the overlay network, see Overlay network in Container-to-Container Networking.

Configure the Number of Diego Cells

To modify the number of Diego Cells supported by the overlay network:

In Tanzu Operations Manager, click the TAS for VMs tile.
Click Networking.
Under Overlay subnet, enter an IP range for the overlay network. By default, Tanzu Operations Manager uses 10.255.0.0/16. Modifying the subnet range allocated to the overlay network changes the number of Diego Cells supported in your deployment. For guidance, see the following table:

Overlay subnet mask	Number of Diego Cells	Containers per Diego Cell
/20	15	254
/16	255	254
/12	4,095	254

The overlay network IP address range must not conflict with any other IP addresses in the network. If a conflict exists, Diego Cells cannot reach any endpoint that has a conflicting IP address.

Create and manage networking policies

This section describes how to create and edit container-to-container networking policies using the Cloud Foundry Command Line Interface (cf CLI).

NoteYou can also create and modify container-to-container networking policies using Apps Manager. For more information, see Create Container-to-Container Networking Policies in the Managing Apps and Service Instances Using Apps Manager topic.

Prerequisites

Ensure that you are using cf CLI v7 or later:

$ cf version

For more information about updating the cf CLI, see Installing the cf CLI.

Grant permissions

Cloud Foundry admins use the following UAA scopes to grant specific users or groups permissions to configure network policies:

UAA Scope	Suitable for…	Allows users to create policies…
`network.admin`	operators	for any apps in the Cloud Foundry deployment
`network.write`	space developers	for apps in spaces that they can access

If you are a Cloud Foundry admin, you already have the network.admin scope. An admin can also grant the network.admin scope to a space developer.

For more information, see Creating and Managing Users with the UAA CLI (UAAC) and Orgs, spaces, roles, and permissions.

To grant all Space Developers permissions to configure network policies, open the App Developer Controls pane in the TAS for VMs tile and enable the Allow space developers to manage network policies check box.

By default, Space Developers can add a maximum of 150 network policies per source app. Operators can increase this limit by changing the Maximum number of network policies per app source property in the App Developer Controls tab. This limit does not apply to users with the network.admin scope.

Add a network policy

To add a policy that allows direct network traffic from one app to another, run:

cf add-network-policy SOURCE-APP DESTINATION-APP -s DESTINATION-SPACE-NAME -o DESTINATION-ORG-NAME --protocol (tcp | udp) --port RANGE

Where:

SOURCE-APP is the name of the app that sends traffic.
DESTINATION-APP is the name of the app that receives traffic.
DESTINATION-SPACE-NAME is the space of the destination app. The default is the targeted space.
DESTINATION-ORG-NAME is the org of the destination app. The default is the targeted org.
PROTOCOL is either: tcp or udp.
RANGE contains the ports at which to connect to the destination app. The allowed range is from 1 to 65535. You can specify a single port, such as 8080, or a range of ports, such as 8080-8090. Port 61443 is used for TLS communication.

Use the add-network-policy command to allows access from the frontend app to the backend app over TCP at port 8080. Here is an example:

$ cf add-network-policy frontend backend --protocol tcp --port 8080
Adding network policy to app frontend in org my-org / space dev as admin...
OK

Space Developers can add up to 150 network policies per space. This limit does not apply to users with the network.admin scope.

List policies

You can list all the policies in your space, or just the policies for which a single app is the source:

To list the all the policies in your space, run cf network-policies.
```
$ cf network-policies
```

To list the policies for an app, run cf network-policies --source MY-APP. Replace MY-APP with the name of your app.

$ cf network-policies --source example-app

The following example of the network-policy command lists policies for the app frontend:

$ cf network-policies --source frontend
Listing network policies in org my-org / space dev as admin...

source      destination   protocol   ports    destination space    destination org
frontend    backend       tcp        8080     example-space        example-org

Remove a network policy

To remove a policy that allows direct network traffic from an app, run:

cf remove-network-policy SOURCE-APP DESTINATION-APP -s DESTINATION-SPACE-NAME -o DESTINATION-ORG-NAME --protocol PROTOCOL --port RANGE

Where:

SOURCE-APP is the name of the app that sends traffic.
DESTINATION-APP is the name of the app that receives traffic.
DESTINATION-SPACE-NAME is the space of the destination app. The default is the targeted space.
DESTINATION-ORG-NAME is the org of the destination app. The default is the targeted org.
PROTOCOL is either tcp or udp.
PORTS are the ports connecting the apps. The allowed range is from 1 to 65535. You can specify a single port, such as 8080, or a range of ports, such as 8080-8090.

The remove-network-policy command deletes the policy that allows the frontend app to communicate with the backend app over TCP on port 8080. Here is an example:

$ cf remove-network-policy frontend backend --protocol tcp --port 8080
Removing network policy to app frontend in org my-org / space dev as admin...
OK

Deactivate network policy enforcement

You can deactivate Silk network policy enforcement between apps. Deactivating network policy enforcement allows all apps to send network traffic to all other apps in the foundation despite no policy specifically allowing it.

To deactivate network policy enforcement between apps:

Go to Tanzu Operations Manager Installation Dashboard.
Click the VMware Tanzu Application Service for VMs tile.
Select Networking.
Deselect the Enforce Silk network policy check box.
Click Save.

App service discovery

With app service discovery, apps pushed to TAS for VMs can establish container-to-container communications through a known route served by internal BOSH DNS. This allows front end apps to easily connect with back end apps.

NoteThe internal domain used for service discovery is apps.internal by default. Operators can modify this value in App Developer Controls pane of the TAS for VMs tile.

To establish container-to-container communications between a front end and back end app, a developer:

Runs a back end app that publishes a local endpoint.
Maps a named route to the endpoint.
Creates a network policy that allows direct traffic from the front end to the back end app.
Run the front end app.

See Cats and Dogs with Service Discovery in GitHub for an example, written in Go, that demonstrates communication between front end and back end apps.

To use TLS developer adds a network policy for port 61443. After that the front end app can reach the back end app using HTTPS, https://backend-app.apps.internal:61443, for example.