anchor.diff:  owner: Container-to-Container Networking
   ---
   
  -This topic provides an overview of how container-to-container networking works in <%= vars.app_runtime_full %> (<%= vars.app_runtime_abbr %>.
  +This topic provides an overview of how container-to-container networking works in <%= vars.app_runtime_full %> (<%= vars.app_runtime_abbr %>).
   
   <p class="note"><strong>Note:</strong> Container-to-container networking is not available for apps hosted on Windows.</p>
   
  
positive.code:     <td>Policy Server</td>
      <td>A central management node that:
        <ul>
          <li>Maintains a database of policies for traffic between apps. 
              The cf CLI 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. This API serves traffic using TLS.</li>
        </ul></td>
    </tr>
    <tr>
      <td>Garden External Networker</td>
      <td> 
        A Garden-runC add-on deployed to every Diego Cell that:
        <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 Application Security Groups (ASGs).</li>
        </ul>
      </td>
    </tr>
  
negative.code: 
  <p class="note warning"><strong>Warning:</strong> 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.</p>
  
  <p class="note"><strong>Note:</strong> Traffic to app containers from the Gorouter or from app containers to external services uses Diego Cell IP addresses and NAT, not the overlay network.</p>
  
  ### <a id="policies"></a> Policies
  
  Enabling container-to-container networking for your deployment allows you to create policies for communication between app instances. The container-to-container 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. Container-to-container networking supports UDP and TCP, and you can configure policies for multiple ports. These policies apply immediately without having to restart the app.
  
  Additionally, policies use and and track the GUIDs of the apps. The policies continue to work when apps redeploy, or if they crash and Diego places them in a new container. Pushing a brand new app requires a new policy, but not updates to an existing app because an app always retains its GUID.
  
  <% if vars.platform_code.include? "CF" %>
  
  
  ## <a id='service-discovery'></a> App Service Discovery
  
  The <%= vars.app_runtime_abbr %> platform supports DNS-based service discovery that lets apps find each other's internal addresses. For example, a front end app instance can use the service discovery mechanism to establish communications with a back end app instance. To set up and use app service discovery, see [App Service Discovery](../devguide/deploy-apps/cf-networking.html#discovery) in _Configuring Container-to-Container Networking_.
  
  Container-to-container app service discovery does not provide client-side load balancing or circuit-breaking, and it does not apply to `cf marketplace` services or require app binding. It just lets apps publish service endpoints to each other, unbrokered and unmediated.
  
  