anchor.diff:  
   1. Decide on the number of TCP routes you want to support. For each TCP route, a port must be reserved. Configure your LB to forward the range of ports to the TCP routers.
   
  -1. <%= partial vars.tcp_port %>
  +1. <%= vars.tcp_port %>
   
   ##<a id="post-deploy"></a> Post-Deployment Steps ##
   
   ###<a id="configure-domain"></a> Configure CF with your TCP Domain ###
   
  -After you’ve deployed CF, you need to configure CF with the domain that you configured in the Pre-deployment step one, so that developers can create TCP routes from it.
  +After you’ve deployed CF, you need to configure CF with the domain that you configured in the Pre-deployment step one above, so that developers can create TCP routes from it.
   
   1. Run `$ cf router-groups`. You should see `default-tcp` as a response.
   
  
positive.code: 
  ###<a id="configure-quota"></a> Configure a Quota for TCP Routes ###
  
  Since TCP route ports are a limited resource in some environments, quotas are configured to allow creation of zero TCP routes by default. After you have deployed CF, you may increase the maximum number of TCP routes for all organizations or for particular organizations and spaces. As a route port is reserved for each TCP route, the quota for this resource is managed with the `--reserved-route-ports` option for the quota CLI commands. See the [Creating and Modifying Quota Plans](../adminguide/quota-plans.html) topic for more information.
  
  If you have a default quota that applies to all organizations, you can update it to configure the number of route ports that may be reserved by each organization.
    <pre class="terminal">
      $ cf update-quota QUOTA —reserved-route-ports X
    </pre>.
  
  To create a new organization quota that can be allocated to particular organizations, you will need to provide several required quota attributes in addition to the number of reserved route ports:
      <pre class="terminal">
        $ cf create-org QUOTA ... --reserved-route-ports X
      </pre>
  
  You can also create a quota that governs the number of route ports that can be created in a particular space. You will need to provide several required quota attributes in addition to the number of reserved route ports:
    <pre class="terminal">
      $ cf create-space-quota QUOTA ... —reserved-route-ports X
    </pre>
  
  ##<a id="router-groups"></a> Router Groups ##
  
  In [Post-Deployment Steps](#configure-domain), we describe that in order to create a domain from which to create TCP routes, it must be associated with the TCP Router Group. A router group is a cluster of identically configured routers. Router Groups were introduced as mechanism to eventually support reservation of the same port for multiple TCP routes, thus increasing the capacity for TCP routes. However, currently only one router group is supported.  In the [Pre-Deployment Steps](#pre-deploy) we describe how an admin can configure the port range available for TCP routes in prepation for deployment.
  
  <%= partial vars.tcp_mod_port_change %>
negative.code: 
  <strong><%= modified_date %></strong>
  
  This topic describes enabling TCP Routing for your Cloud Foundry (CF) deployment. This feature enables developers to run applications that serve requests on non-HTTP TCP protocols. You can utilize TCP Routing to comply with regulatory requirements that require your organization to terminate the TLS as close to your apps as possible so that packets are not decrypted before reaching the application level.
  
  ##<a id="ports"></a> Route Ports ##
  
  The diagram below shows the layers of network address translation that occur in Cloud Foundry in support of TCP Routing. The description below walk through an example work flow that covers route ports, backend ports, and app ports.
  
  ![Route Ports](./images/route_ports.png)
  
  - A developer creates a TCP route for their application based on a TCP domain and a route port, and maps this route to one or more applications. See the [Creating Routes](../devguide/deploy-apps/routes-domains.html#create-route) topic for more information.
  - Clients make requests to the route. DNS resolves the domain name to the load balancer.
  - The load balancer listens on the port and forwards requests for the domain to the TCP routers. The load balancer must listen on a range of ports to support multiple TCP route creation. Additionally, Cloud Foundry must be configured with this range, so that the platform knows what ports can be reserved when developers create TCP routes.
  - The TCP router can be dynamically configured to listen on the port when the route is mapped to an application. The domain the request was originally sent to is no longer relevant to the routing of the request to the application. The TCP router keeps a dynamically updated record of the backends for each route port. The backends represent instances of an application mapped to the route. The TCP router chooses a backend using a round-robin load balancing algorithm, and forwards the request to it.
  - Because containers each have their own private network, the TCP router does not have direct access to application containers. When a container is created for an application instance, a port on the Cell VM is randomly chosen and iptables are configured to forward requests for this port to the internal interface on the container. The TCP router then receives a mapping of the route port to the Cell IP and port.
  - The Diego Cell only routes requests to port 8080, the App Port, on the container internal interface. The App Port is the port on which applications must listen.
  
  ##<a id="pre-deploy"></a> Pre-Deployment Steps ##
  
  