anchor.diff:  
   #### <a id='create-route-with-wildcard-hostname'></a> Create an HTTP Route with Wildcard Hostname
   
  -An app mapped to a wildcard route acts as a fallback app for route requests if the requested route does not exist. To create a wildcard route, use an asterisk for the hostname.
  +An app mapped to a wildcard route acts as a fallback app for route requests if the requested route does not exist. To create a wildcard route, use an asterisk
  +for the hostname.
   
   A developer can create a wildcard route from the domain `foo.<%= vars.app_domain %>` by running:
   
   * **cf CLI v7**
     <pre class="terminal">
     $ cf create-route foo.<%= vars.app_domain %> --hostname '*'
  -  Creating route *.foo.<%= vars.app_domain %> for org my-org / space my-space as username<span>@</span>example.com...
  +  Creating route *.foo.<%= vars.app_domain %> for org example-org / space example-space as username<span>@</span>example.com...
     OK
     </pre>
   * **cf CLI v6**
     <pre class="terminal">
  -  $ cf create-route my-space foo.<%= vars.app_domain %> --hostname '*'
  -  Creating route *.foo.<%= vars.app_domain %> for org my-org / space my-space as username<span>@</span>example.com...
  -  OK
  -  </pre>
  -
  -If a client sends a request to `http://app.foo.<%= vars.app_domain %>` by accident, attempting to reach `myapp.foo.<%= vars.app_domain %>`, <%= vars.app_runtime_abbr %> routes the request to the app mapped to the route `*.foo.<%= vars.app_domain %>`.
  +  $ cf create-route example-space foo.<%= vars.app_domain %> --hostname '*'
  +  Creating route *.foo.<%= vars.app_domain %> for org example-org / space example-space as username<span>@</span>example.com...
  +  OK
  +  </pre>
  +
  +If a client sends a request to `http://app.foo.<%= vars.app_domain %>` by accident, attempting to reach `example-app.foo.<%= vars.app_domain %>`,
  +<%= vars.app_runtime_abbr %> routes the request to the app mapped to the route `*.foo.<%= vars.app_domain %>`.
   
   #### <a id='create-route-with-path'></a> Create an HTTP Route with a Path
   
   Developers can use paths to route requests for the same hostname and domain to different apps.
   
  -A developer can create three routes using the same hostname and domain in the space `my-space` by running:
  +A developer can create three routes using the same hostname and domain in the space `example-space` by running:
   
   * **cf CLI v7**
     <pre class="terminal">
     $ cf create-route <%= vars.app_domain %> --hostname store --path products
  -  Creating route store.<%= vars.app_domain %>/products for org my-org / space my-space as username<span>@</span>example.com...
  +  Creating route store.<%= vars.app_domain %>/products for org example-org / space example-space as username<span>@</span>example.com...
     OK
     </pre>
     <pre class="terminal">
     $ cf create-route <%= vars.app_domain %> --hostname store --path orders
  -  Creating route store.<%= vars.app_domain %>/orders for org my-org / space my-space as username<span>@</span>example.com...
  +  Creating route store.<%= vars.app_domain %>/orders for org example-org / space example-space as username<span>@</span>example.com...
     OK
     </pre>
     <pre class="terminal">
     $ cf create-route <%= vars.app_domain %> --hostname store
  -  Creating route store.<%= vars.app_domain %> for org my-org / space my-space as username<span>@</span>example.com...
  +  Creating route store.<%= vars.app_domain %> for org example-org / space example-space as username<span>@</span>example.com...
     OK
     </pre>
   * **cf CLI v6**
  -  <p class="note"><strong>Note:</strong> If you want to create a route without a path using cf CLI v6, you must run the commands in the order below. Create the route without a path first, and then create any routes with a path. If you do not need a route without a path, then this order is not required.</p>
  -  <pre class="terminal">
  -  $ cf create-route my-space <%= vars.app_domain %> --hostname store
  -  Creating route store.<%= vars.app_domain %> for org my-org / space my-space as username<span>@</span>example.com...
  -  OK
  -  </pre>
  -  <pre class="terminal">
  -  $ cf create-route my-space <%= vars.app_domain %> --hostname store --path products
  -  Creating route store.<%= vars.app_domain %>/products for org my-org / space my-space as username<span>@</span>example.com...
  -  OK
  -  </pre>
  -  <pre class="terminal">
  -  $ cf create-route my-space <%= vars.app_domain %> --hostname store --path orders
  -  Creating route store.<%= vars.app_domain %>/orders for org my-org / space my-space as username<span>@</span>example.com...
  +  <p class='note'><strong>Note:</strong> If you want to create a route without a path using cf CLI v6, you must run the commands in the order below. Create
  +    the route without a path first, and then create any routes with a path. If you do not need a route without a path, then this order is not required.</p>
  +  <pre class="terminal">
  +  $ cf create-route example-space <%= vars.app_domain %> --hostname store
  +  Creating route store.<%= vars.app_domain %> for org example-org / space example-space as username<span>@</span>example.com...
  +  OK
  +  </pre>
  +  <pre class="terminal">
  +  $ cf create-route example-space <%= vars.app_domain %> --hostname store --path products
  +  Creating route store.<%= vars.app_domain %>/products for org example-org / space example-space as username<span>@</span>example.com...
  +  OK
  +  </pre>
  +  <pre class="terminal">
  +  $ cf create-route example-space <%= vars.app_domain %> --hostname store --path orders
  +  Creating route store.<%= vars.app_domain %>/orders for org example-org / space example-space as username<span>@</span>example.com...
     OK
     </pre>
   
   The developer can then map the new routes to different apps by following the steps in [Map a Route to Your App](#map-route).
   
  -If the developer maps the first route with path `products` to the `products` app, the second route with path `orders` to the `orders` app, and the last route to the `storefront` app. After this:
  +If the developer maps the first route with path `products` to the `products` app, the second route with path `orders` to the `orders` app, and the last route
  +to the `storefront` app. After this:
   
   * <%= vars.app_runtime_abbr %> routes requests to `http://store.<%= vars.app_domain %>/products` to the `products` app.
   * <%= vars.app_runtime_abbr %> routes requests to `http://store.<%= vars.app_domain %>/orders` to the `orders` app.
  
positive.code:         app.apps.internal has address 10.255.49.7
          app.apps.internal has address 10.255.49.77
         </pre>
      - To resolve individual instances, prepend the index to the internal route.
        <pre class="terminal">
        vcap@1234:~$ host 1.app.apps.internal
        1.app.apps.internal has address 10.255.49.7
        </pre>
  
  1. Create a network policy that allows your apps to communicate with each other. By default, apps cannot communicate over the container network. For more information, see [Configuring Container-to-Container Networking](./cf-networking.html) and [add-network-policy](https://cli.cloudfoundry.org/en-US/cf/add-network-policy.html) in the _Cloud Foundry CLI Reference Guide_.
  
  ### <a id='create-route'></a> Create a Route
  
  When a developer creates a route using the cf CLI, <%= vars.app_runtime_abbr %> determines whether the route is an HTTP or a TCP route based on the domain. To create a HTTP route, a developer must choose an HTTP domain. To create a TCP route, a developer must choose a TCP domain.
  
  Domains in <%= vars.app_runtime_abbr %> provide a namespace from which to create routes. To list available domains for a targeted organization, use the [cf domains](https://cli.cloudfoundry.org/en-US/cf/domains.html) command. For more information about domains, see [Domains](#domains).
  
  The following sections describe how developers can create HTTP and TCP routes for different use cases.
  
  #### <a id='create-route-with-hostname'></a> Create an HTTP Route with Hostname
  
  In <%= vars.app_runtime_abbr %>, a hostname is the label that indicates a subdomain of the domain associated with the route. Given a domain `<%= vars.app_domain %>`, a developer can create the route `myapp.<%= vars.app_domain %>` by specifying the hostname `myapp` with the [cf create-route](https://cli.cloudfoundry.org/en-US/cf/create-route.html) command as shown in this example:
  
  * **cf CLI v7**
    <pre class="terminal">
    $ cf create-route <%= vars.app_domain %> --hostname myapp
    Creating route myapp.<%= vars.app_domain %> for org my-org / space my-space as username<span>@</span>example.com...
    OK
    </pre>
    <p class="note"><strong>Note:</strong> The cf CLI v7 <code>create-route</code> command does not require the space as an argument. It uses the space you are currently targeting.</p>
  * **cf CLI v6**
    <pre class="terminal">
    $ cf create-route my-space <%= vars.app_domain %> --hostname myapp
    Creating route myapp.<%= vars.app_domain %> for org my-org / space my-space as username<span>@</span>example.com...
    OK
    </pre>
  
  This command instructs <%= vars.app_runtime_abbr %> to only route requests to apps mapped to this route for the following URLs:
  
  * `http://myapp.<%= vars.app_domain %>`
  * `https://myapp.<%= vars.app_domain %>`
  * Any path under either of the above URLs, such as `http://myapp.<%= vars.app_domain %>/bar`
  
  #### <a id='create-route-without-hostname'></a> Create an HTTP Route without Hostname
  
  This approach creates a route with the same address as the domain itself and is permitted for private domains only. For more information, see [Private Domains](#private-domains).
  
  A developer can create a route from the domain `<%= vars.private_app_domain %>` with no hostname with the [cf create-route](https://cli.cloudfoundry.org/en-US/cf/create-route.html) command:
  
  * **cf CLI v7**
    <pre class="terminal">
    $ cf create-route <%= vars.private_app_domain %>
    Creating route <%= vars.private_app_domain %> for org my-org / space my-space as username<span>@</span>example.com...
    OK
    </pre>
  * **cf CLI v6**
    <pre class="terminal">
    $ cf create-route my-space <%= vars.private_app_domain %>
    Creating route <%= vars.private_app_domain %> for org my-org / space my-space as username<span>@</span>example.com...
    OK
    </pre>
  
  
negative.code: example-org---
  title: Configuring Routes and Domains
  owner: CF for VMs Networking
  ---
  
  <% $this_topic = 'routes-domains' %>
  
  This topic describes how routes and domains work in <%= vars.app_runtime_full %> (<%= vars.app_runtime_abbr %>), and how developers and administrators
  configure routes and domains for their apps using the Cloud Foundry Command Line Interface (cf CLI).
  
  For more information about routing capabilities in <%= vars.app_runtime_abbr %>, see [HTTP Routing](../../concepts/http-routing.html).
  
  
  ## <a id='routes'></a> Routes
  
  The <%= vars.app_runtime_abbr %> Gorouter routes requests to apps by associating an app with an address, known as a route. This is known as a _mapping_. Use
  the cf CLI [cf map-route](https://cli.cloudfoundry.org/en-US/cf/map-route.html) command to associate an app and route.
  
  The routing tier compares each request with a list of all the routes mapped to apps and attempts to find the best match. For example, the Gorouter would make
  the following matches for the two routes `example-app.<%= vars.app_domain %>` and `example-app.<%= vars.app_domain %>/products`:
  
  | Request | Matched Route |
  | ------- | ------------- |
  | http://example-app.<%= vars.app_domain %> | example-app.<%= vars.app_domain %> |
  | http://example-app.<%=vars.app_domain%>/contact | example-app.<%=vars.app_domain%> |
  | http://example-app.<%= vars.app_domain %>/products | example-app.<%= vars.app_domain %>/products |
  | http://example-app.<%= vars.app_domain %>/products/123 | example-app.<%= vars.app_domain %>/products |
  | http://products.<%= vars.app_domain %> | No match; 404 |
  
  The Gorouter does not use a route to match requests until the route is mapped to an app. In the above example, `products.<%= vars.app_domain %>` may have been
  created as a route in <%= vars.app_runtime_abbr %>, but until it is mapped to an app, requests for the route receive a `404` error.
  
  The routing tier knows the location of instances for apps mapped to routes. Once the routing tier determines a route as the best match for a request, it makes
  a load-balancing calculation using a round-robin algorithm, and forwards the request to an instance of the mapped app.
  
  Developers can map many apps to a single route, resulting in load-balanced requests for the route across all instances of all mapped apps. This approach
  enables the blue/green rolling deployment strategy. Developers can also map an individual app to multiple routes, enabling access to the app from many URLs.
  The number of routes that can be mapped to each app is approximately 1000 (128&nbsp;KB).
  
  Routes belong to a space, and developers can only map apps to a route in the same space.
  
  <p class='note'><strong>Note:</strong> Routes are globally unique. Developers in one space cannot create a route with the same URL as developers in another
    space, regardless of which orgs control these spaces.</p>
  
  ### <a id='http-vs-tcp-routes'></a> HTTP vs. TCP Routes
  
  <p class='note'><strong>Note:</strong> By default, <%= vars.app_runtime_abbr %> only supports routing of HTTP requests to apps.</p>
  
  Routes are considered HTTP if they are created from HTTP domains, and TCP if they are created from TCP domains. For more information, see [HTTP vs. TCP Shared
  Domains](#http-vs-tcp-shared-domains) below.
  
  HTTP routes include a domain, an optional hostname, and an optional context path. `<%= vars.app_domain %>`, `example-app.<%= vars.app_domain %>`, and
  `example-app.<%= vars.app_domain %>/products` are all examples of HTTP routes. Apps should listen to the `localhost` port defined by the `$PORT` environment
  variable, which is `8080` on Diego. As an example, requests to `example-app.<%= vars.app_domain %>` would be routed to the app container at `localhost:8080`.
  
  <p class='note'><strong>Note:</strong> Developers can use the Cloud Controller API to update the ports an app can receive requests on. For more information,
    see <a href="../custom-ports.html">Configuring Apps to Listen on Custom Ports (Beta)</a>.</p>
  
  * Requests to HTTP routes must be sent to ports 80 or 443.
  * Ports cannot be reserved for HTTP routes.
  
  TCP routes include a domain and a route port. A route port is the port clients make requests to. This is not the same port as what an app pushed to Cloud
  Foundry listens on. `tcp.shared-domain.example.com:60000` is an example of a TCP route. Just as for HTTP routes, apps should listen to the `localhost` port
  defined by the `$PORT` environment variable, which is `8080` on Diego. As an example, requests to `tcp.shared-domain.example.com:60000` would be routed to the
  app container at `localhost:8080`.
  
  * Once a port is reserved for a route, it cannot be reserved for another route.
  * Hostname and path are not supported for TCP routes.
  