anchor.diff:  - 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 for each new TCP connection from a client. As the TCP Router is protocol agnostic, it does not recognize individual requests, only TCP connections. All client requests transit the same connection to the selected backend until the client or backend closes the connection. Each subsequent connection  triggers the selection of a backend. 
  +- 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 for each new TCP connection from a client. As the TCP Router is protocol agnostic, it does not recognize individual requests, only TCP connections. All client requests transit the same connection to the selected backend until the client or backend closes the connection. Each subsequent connection  triggers the selection of a backend.
   - 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 ##
  +
  +<%= vars.mutual_tls_tcp %>
   
   Before enabling TCP Routing, you must complete the following steps to set up networking requirements.
   
  
positive.code: $ cf create-quota 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. 
  <pre class="terminal">
  $ cf create-space-quota QUOTA —reserved-route-ports X
  </pre>
  
negative.code:       }
      ]
    </pre>
  
  1. Modify the `reservable_ports`:
  
      <pre class="terminal">
  