* After an internal route is mapped to an app, the route resolves to IP addresses of the app instances. The IP addresses are visible in the application container:

* To resolve individual instances, prepend the index to the internal route.

2. 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 the [Cloud Foundry CLI reference guide](https://cli.cloudfoundry.org/en-US/cf/add-network-policy.html).

<li>Any path under either of the these URLs, such as <code>http://example-app.<%= vars.app_domain %>/bar</code></li>

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) .

* `https://foo.<%= vars.private_app_domain %>`

* Any path under either of these URLs, such as `http://foo.<%= vars.private_app_domain %>/foo`

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 host name.

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 %>`.

Developers can use paths to route requests for the same host name and domain to different apps.

</ul>

A developer can create a TCP route for `<%= vars.tcp_app_domain %>` on an arbitrary port. This is the default in the v7 version of the cf CLI.

Changes to route mappings are run asynchronously. On startup, an app becomes accessible at its route within a few seconds. Similarly, upon mapping a new route to a running app, the app becomes accessible at this route within a few seconds of the CLI exiting.

For these routes and apps:

$ cf map-route h2app <%= vars.app_domain %> --hostname h2app --destination-protocol http2

```

Developers can map a route to their app with the `cf push` command.

As of cf CLI v7, the best way to do this is by using the `routes` property in the manifest.

$ cf push tcp-app -d <%= vars.tcp_app_domain %> --random-route

```

Developers can map a route to their app with a manifest by editing the `route` attribute to specify the host, domain, port, and path components of the route. For more information, see [Deploying with app manifests](../deploy-apps/manifest.html#routes).

<%= partial 'routing_conflict' %>

For more information about troubleshooting this problem, see [Routing conflict](troubleshoot-app-health.html#routing-conflict) in _Troubleshooting app deployment and health_.

You can have multiple routes to an app, but those routes cannot have different context paths.

</tr>

You can map an internal route to any app. This internal route allows your app to communicate with other apps without leaving the platform. After it is mapped, this route becomes available to all other apps on the platform.

Shared domains are HTTP by default, but can be configured to be TCP when associated with the TCP router group.

Admins can create an HTTP shared domain with the `cf create-shared-domain` command:

```console

$ cf create-shared-domain <%= vars.tcp_app_domain %> --router-group default-tcp

```

Admins can delete a shared domain from <%= vars.app_runtime_abbr %> with the `cf delete-shared-domain` command:

```console

$ cf delete-shared-domain example.com

```

The internal domain is a special type of shared domain used for app communication internal to the platform. When you activate service discovery, the internal domain `apps.internal` becomes available for route mapping.

Private domains can be HTTP or HTTPS only. TCP routing is supported for shared domains only.

Org managers can create a private domain by running:

$ cf create-private-domain example-org foo.<%= vars.private_app_domain %>

```

Org managers can grant or revoke access to a private domain to other orgs if they have permissions for these orgs.

As of cf CLI v7, `cf unshare-private-domain` command provides a warning and requires confirmation before it proceeds.