container-networking.html.md.erb

---
title: Administering CF Networking
owner: CF Networking
---

This topic provides an overview of CF Networking and describes how to enable and use the feature.

##<a id="about"></a>About CF Networking

The Diego cells, which host apps in CF, run each app instance in a container.
When the CF Networking feature is enabled, app instances (containers) can communicate with each other directly.
When the CF Networking feature is disabled, all app-to-app traffic must go through the Gorouter.

###<a id="overview"></a> Overview

Enabling CF Networking for your deployment allows you to create policies for communication between app instances.
The CF Networking feature also provides a unique IP address to each app container, and provides direct IP reachability between app instances.

The policies you create specify a source app, destination app, protocol, and port so that app instances can communicate directly 
without going through the Gorouter, a load balancer, or a firewall. 
CF Networking supports UDP and TCP, and you can configure policies for multiple ports. 
These policies apply immediately without having to restart the app. For more information, see <a href="#create-policies">Create Policies for CF Networking</a> below.

The BOSH release that contains the CF Networking feature is composed of a 
pluggable network stack.  Advanced users or 3rd party vendors may integrate a different network stack into Cloud Foundry.

For more information, see [Architecture](#architecture) below and docs in the [CF Networking BOSH release](https://github.com/cloudfoundry-incubator/cf-networking-release/blob/develop/docs/3rd-party.md). 


#### Without CF Networking

The diagram below illustrates how two app instances communicate in a deployment without CF Networking enabled. 
Traffic from **App A** must route out and back in through the Gorouter, 
which restricts performance and the protocol used to send the traffic. 
In this scenario, **App B** does not know the real source of the traffic it receives and must trust all inbound traffic. 

![Pre CF Networking](./images/pre-c2c.png)

#### With CF Networking

The diagram below illustrates how app instances communicate in a deployment with CF Networking enabled. 
In this example, the operator creates two policies to regulate the flow of traffic between **App A**, **App B**, and **App C**. 

* Allow traffic from **App A** to **App B**
* Allow traffic from **App A** to **App C**

If traffic and its direction is not explicitly allowed, it is denied. For example, **App B** cannot send traffic to **App C**.

![Post CF Networking](./images/post-c2c.png)

###<a id="c2cvsasg"></a> CF Networking versus ASGs

Both application security groups (ASGs) and CF Networking policies affect traffic from app instances.
The following table highlights differences between ASGs and CF Networking policies.

<table>
  <tr>
   <th></th>
   <th>ASGs</th>
   <th>CF Networking Policies</th>
  <tr>
  <tr>
   <th>Policy granularity</th>
   <td>From a space to an IP address range</td>
   <td>From a source app to a destination app</td>
  </tr>
  <tr>
   <th>Scope</th>
   <td>For a space, org, or deployment</td>
   <td>For app to app only</td>
  </tr>
  <tr>
   <th>Traffic direction</th>
   <td>Outbound control</td>
   <td>Policies apply for incoming packets from other app instances</td>
  </tr>
  <tr>
   <th>Source app</th>
   <td>Is not known</td>
   <td>Is identified because of direct addressability</td>
  </tr>
  <tr>
   <th>Policies take affect</th>
   <td>After app restart</td>
   <td>Immediately</td>
  </tr>
</table>
    
###<a id="architecture"></a> Architecture

CF Networking integrates with Garden-runC in a Diego deployment. 
The BOSH release for CF Networking includes several core components, as well as swappable components. 

To understand the components and how they work, see the diagram and tables below. 
The diagram displays the CF Networking components in blue and other CF components in gray. 
The diagram also highlights swappable components in yellow. 

![c2c architecture diagram](./images/c2c-arch.png)

#### Core Components

The core components included in the CF Networking BOSH release are as follows:

<table>
  <tr>
    <th>Part</th>
    <th>Function</th>
  </tr>
  <tr>
    <td>Cloud Foundry Command Line Interface (CF CLI) plugin</td>
    <td>A plugin that you download to control network access policies between apps. 
        See <a href="#create-policies">Create Policies for CF Networking</a>.</td>
  </tr>
  <tr>
    <td>Policy Server</td>
    <td>A central management node that does the following:
      <ul>
        <li>Maintains a database of policies for traffic between apps. 
            The CF CLI plugin calls an API to create or update a record 
            in the policy database whenever you create or remove a policy.</li>
        <li>Exposes a JSON REST API used by the CF CLI plugin</li>
      </ul></td>
  </tr>
  <tr>
    <td>Garden External Networker</td>
    <td> 
      A Garden-runC add-on deployed to every Diego cell that does the following:
      <ul>
        <li>Invokes the CNI plugin component to set up the network for each app</li>
        <li>Forwards ports to support incoming connections from the Gorouter, TCP Router, and Diego SSH Proxy. 
            This keeps apps externally reachable.</li>
        <li>Installs outbound whitelist rules to support CF Application Security Groups (ASGs). 
            See the <a href="app-sec-groups.html">ASG documentation</a>.</li>
      </ul>
    </td>
  </tr>
</table>

#### Swappable Components

The swappable components included in the CF Networking BOSH release are as follows:

<table>
  <tr>
    <th>Part</th>
    <th>Function</th>
  </tr>
  <tr>
  <td>Flannel CNI plugin<br></td>
  <td>A plugin that provides IP address management and network connectivity to apps.
  <ul>
  <li>Acquires IP address of container and relays to Garden</li>
  <li>Installs network interface in container using the the flannel VXLAN backend. This is a shared, flat L3 network.</li>
  </td>
  </ul>
  </tr>
  <tr>
  <td>VXLAN Policy Agent<br></td>
  <td>Enforces network policy for traffic between apps as follows:
  <ul>
  <li>Discovers desired network policies from the Policy Server Internal API</li>
  <li>Updates iptables rules on Diego cell to allow whitelisted inbound traffic </li>
  <li>Tags outbound traffic with the unique identifier of the source app using the VXLAN Group-Based Policy (GBP) header</li>
  </ul>
  </td>
  </tr>
</table> 

##<a id="enable"></a>Enable CF Networking

<% if vars.product_name == 'PCF' %>
 <%= partial "../customizing/c2c_pcf_enable" %>
 <% else %>
 <%= partial 'c2c_oss_enable' %>
 <% end %>

##<a id="create-policies"></a>Create Policies for CF Networking

This section describes how to create and modify CF Networking policies using a plugin for the CF CLI.

To use the plugin, you must have the `network.admin` UAA scope. This scope gives you the right to create a policy between any two apps in your CF deployment. 
Depending on the security structure of your organization, you can either assign this scope to developers
so that they can create their own policies or you can have your developers send you requests.
For more information, see [Creating and Managing Users with the UAA CLI (UAAC)](./uaa-user-management.html).

### Install the Plugin

Follow these steps to download and install the Network Policy plugin for the CF CLI:

1. Download the `network-policy-plugin` for your operating system from the 
   [CF Networking Release repository](https://github.com/cloudfoundry-incubator/cf-networking-release/releases).

1. To change the permissions of the plugin file and complete the installation, enter the following commands:

    <pre>
    $ chmod +x ~/Downloads/network-policy-plugin
    $ cf install-plugin ~/Downloads/network-policy-plugin
    </pre>

### Create a Policy

To create a policy that allows direct network traffic from one app to another, enter the following command:

<pre>
$ cf allow-access SOURCE-APP DESTINATION-APP --protocol PROTOCOL --port PORT
</pre>

Where:<br>
`SOURCE-APP` is the name of the app that will be sending traffic.<br>
`DESTINATION-APP` is the name of the app that will be receiving traffic.<br>
`PROTOCOL` is one of the following: `tcp` or `udp`.<br>
`PORT` is the port at which to connect to the destination app. The allowed range is 1 to 65535.<br>


For example, 

<pre class="terminal">
$ cf allow-access frontend backend --protocol tcp --port 8080
Allowing traffic from frontend to backend as admin...
OK 
</pre>

### List Policies

You can list all the policies in your deployment or just the policies for which a single app is 
either the source or the destination:

+ To list the all the policies in your deployment, enter the following command:

    <pre>
    $ cf list-access
    </pre>
+ To list the policies for an app, enter the following command:

    <pre>
    $ cf list-access --app MY-APP
    </pre>

    For example,
    
    <pre class="terminal">
    $ cf list-access --app frontend
    Listing policies as admin...
    OK
    
    Source    Destination    Protocol    Port
    frontend  backend        tcp         8080
    </pre>

### Delete a Policy

To delete a policy that allows direct network traffic from one app to another, enter the following command:

<pre>
$ cf remove-access SOURCE-APP DESTINATION-APP --protocol PROTOCOL --port PORT
</pre>

For example,
<pre class="terminal">
$ cf remove-access frontend backend --protocol tcp --port 8080
Denying traffic from frontend to backend as admin...
OK 
</pre>