anchor.diff:  1. Modify the `reservable_ports`:
   
       <pre class="terminal">
  -    $ cf curl /routing/v1/router_groups/f7392031-a488-4890-8835-c4a038a3bded -X PUT -d '{"reservable_ports":"1024-1199"}'
  +    $ cf curl \
  +    -X PUT -d '{"reservable_ports":"1024-1199"}' \
  +    /routing/v1/router_groups/f7392031-a488-4890-8835-c4a038a3bded
       </pre>
  
positive.code: 1. <%= partial vars.tcp_port %>
  
  
  ## <a id="post-deploy"></a> Post-Deployment Steps
  
  In the following procedures, you use the Cloud Foundry Command Line Interface (cf CLI) to add the TCP shared domain and configure org quotas to grant developers the ability to create TCP routes. This requires an admin user account.
  
  For more information about the cf CLI, see [Using the Cloud Foundry Command Line Interface (cf CLI)](../cf-cli/index.html).
  
  ### <a id="configure-domain"></a> Configure <%= vars.app_runtime_abbr %> with Your TCP Domain
  
  After deployment, you must configure <%= vars.app_runtime_abbr %> with the domain that you configured in the pre-deployment step above so developers can create TCP routes from it.
  
  
negative.code: 
  - 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, <%= vars.app_runtime_abbr %> must be configured with this range, so that the platform knows what ports can be reserved when developers create TCP routes.
  
  - The TCP routers are organized into router groups. A router group is a cluster of identically configured routers. Router groups are a mechanism to support reservation of the same port for multiple TCP routes, thus increasing the capacity for TCP routes. However, only one router group is currently supported.
  
  - The TCP router can be dynamically configured to listen on the port when the route is mapped to an app. The domain the request was originally sent to is no longer relevant to the routing of the request to the app. The TCP router keeps a dynamically updated record of the back ends for each route port. The back ends represent instances of an app mapped to the route. The TCP router chooses a back end 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 back end until the client or back end closes the connection. Each subsequent connection  triggers the selection of a back end.
  
  - Because containers each have their own private network, the TCP router does not have direct access to app containers. When a container is created for an app instance, a port on the Diego 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 Diego Cell IP and port.
  