routing-is.html.md.erb

---
title: Routing for isolation segments in Cloud Foundry
owner: CF for VMs Networking
---

<%# Reset page title based on platform type %>
<% if vars.platform_code != 'CF' %>

<% set_title("Routing for isolation segments in", vars.app_runtime_abbr) %>

<% end %>

You can configure and manage routing for isolation segments in <%= vars.app_runtime_abbr %> as described in this topic. You can also deploy a set of Gorouters for each isolation segment to handle requests for apps within the segment.

For more information about how isolation segments work, see [Isolation Segments](../concepts/security.html#isolation-segments) in _<%= vars.app_runtime_abbr %> Security_. <%= vars.install_isolation_segments %>

<p> The instructions in this topic assume you are using Google Cloud Platform (GCP). The procedures can differ on other IaaSes, but the
concepts must be transferable.</p>


## <a id='overview'></a> Isolation segments overview

Isolation segments isolate the compute resources for one group of apps from another. However, these apps still share the same network resources. Requests for apps on all isolation segments, as well as for system components, transit the same load balancers, <%= vars.app_runtime_abbr %> Gorouters, and <%= vars.app_runtime_abbr %> TCP Routers.

When you use isolation segments, <%= vars.app_runtime_abbr %> designates its Diego Cells as belonging to an isolation segment called `shared`. This isolation segment is the default isolation segment assigned to every org and space. This can be overwritten by assigning an explicit default for an organization. <%= vars.install_isolation_segments %>

The following illustration shows isolation segments sharing the same network resources:

![alt-text="Diagram shows two isolation segments that share Gorouter, TCP Router, load balancer, and other CF components."](./images/routing-is.png)

The two isolation segments each contain a single Diego Cell. These isolation segments use the same Gorouter, TCP Router, and load balancers.

Operators who want to prevent all isolation segments and system components from using the same network resources can deploy an additional set of Gorouters for each isolation segment:

![alt-text="Diagram shows a set of Gorouters deployed for each isolation segment, while sharing other network resources."](./images/is-distinct-domains.png)

The two isolation segments each use separate Gorouters and Diego Cells. However, the use of an isolated TCP router in this scenario is not supported.

Use cases include:

* Requests for apps in an isolation segment must not share networking resources with requests for other apps.

* The <%= vars.app_runtime_abbr %> management plane can only be accessible from a private network. As multiple IaaS load balancers cannot typically share the same pool of back ends, such as <%= vars.app_runtime_abbr %> Gorouters, each load balancer requires an additional deployment of Gorouters.


## <a id='create-networks'></a> Step 1: Create networks

Create a network or subnet for each isolation segment on your infrastructure. For example, an operator who wants one isolation segment separated from their <%= vars.app_runtime_abbr %> Diego Cells could create one network named `sample-network` with two subnets named `sample-subnet-<%= vars.app_runtime_abbr_lc %>` and `sample-subnet-is1`.

The following diagram describes the network topology:

```
IaaS network: sample-network
  |
  |_____ IaaS subnet: sample-subnet-<%= vars.app_runtime_abbr_lc %>
  |
  |_____ IaaS subnet: sample-subnet-is1
```

Subnets do not generally span IaaS availability zones (AZs), so the same operator with two AZs needs four subnets.

```
IaaS network: sample-network
|
|_____ IaaS subnet: sample-subnet-<%= vars.app_runtime_abbr_lc %>-az1
|
|_____ IaaS subnet: sample-subnet-<%= vars.app_runtime_abbr_lc %>-az2
|
|_____ IaaS subnet: sample-subnet-is1-az1
|
|_____ IaaS subnet: sample-subnet-is1-az2

```

For more information about networks and subnets in GCP, see [Using Networks and Firewalls](https://cloud.google.com/compute/docs/networking) in the GCP documentation.


## <a id='config-networks'></a> Step 2: Configure networks for Gorouters

To configure the subnets with BOSH, use BOSH cloud config subnets. Each subnet in the IaaS must correspond to a BOSH subnet that is labeled with the correct isolation segment. For more information, see [Usage](https://bosh.io/docs/cloud-config.html) in the BOSH documentation.

<% if vars.platform_code == 'CF' %>

These are examples of cloud config for GCP and AWS for the four example subnets described in [Step 1: Create Networks](#create-networks).

### GCP Cloud Config

```
azs:
- name: z1
  cloud_properties:
    zone: us-east1-b
- name: z2
  cloud_properties:
    zone: us-east1-c
- name: z3
  cloud_properties:
    zone: us-east1-b
- name: z4
  cloud_properties:
    zone: us-east1-c
networks:
- name: default
  type: manual
  subnets:
  - range: 10.0.0.0/16
    gateway: 10.0.0.1
    reserved:
    - 10.0.16.2-10.0.16.3
    - 10.0.31.255
    static:
    - 10.0.31.190-10.0.31.254
    <strong>az: z1</strong>
    cloud_properties:
      ephemeral_external_ip: true
      <strong>network_name: sample-network</strong>
      <strong>subnetwork_name: sample-subnet-<%= vars.app_runtime_abbr_lc %>-az1</strong>
      tags:
      - <strong>sample-<%= vars.app_runtime_abbr_lc %>-is</strong>
  - range: 10.1.16.0/20
    gateway: 10.1.16.1
    reserved:
    - 10.1.16.2-10.1.16.3
    - 10.1.31.255
    static:
    - 10.1.31.190-10.1.31.254
    <strong>az: z2</strong>
    cloud_properties:
      ephemeral_external_ip: true
      <strong>network_name: sample-network</strong>
      <strong>subnetwork_name: sample-subnet-<%= vars.app_runtime_abbr_lc %>-az2</strong>
      tags:
      - <strong>sample-<%= vars.app_runtime_abbr_lc %>-is</strong>
  - range: 10.0.200.0/28
    gateway: 10.0.200.1
    reserved:
    - 10.0.200.2-10.0.200.3
    - 10.0.200.15
    static:
    - 10.0.200.11-10.0.200.15
    <strong>az: z3</strong>
    cloud_properties:
      ephemeral_external_ip: true
      <strong>network_name: sample-network</strong>
      <strong>subnetwork_name: sample-subnet-is1-az1</strong>
      tags:
      - <strong>sample-is1</strong>
  - range: 10.1.200.0/28
    gateway: 10.1.200.1
    reserved:
    - 10.1.200.2-10.1.200.3
    - 10.1.200.15
    static:
    - 10.1.200.11-10.1.200.15
    <strong>az: z4</strong>
    cloud_properties:
      ephemeral_external_ip: true
      <strong>network_name: sample-network</strong>
      <strong>subnetwork_name: sample-subnet-is1-az2</strong>
      tags:
      - <strong>sample-is1</strong>
```

### AWS cloud config

<p> AWS networking requires security groups, which need to be created separately. In the following example, the operator must create the <strong>sample-<%= vars.app_runtime_abbr_lc %>-is</strong> and <strong>sample-is1</strong> security groups.</p>

```
azs:
- name: z1
  cloud_properties:
  zone: us-east1-b
- name: z2
  cloud_properties:
  zone: us-east1-c
- name: z3
  cloud_properties:
  zone: us-east1-b
- name: z4
  cloud_properties:
  zone: us-east1-c
networks:
- name: default
  type: manual
  subnets:
  - range: 10.0.0.0/16
    gateway: 10.0.0.1
    reserved:
    - 10.0.16.2-10.0.16.3
    - 10.0.31.255
    static:
    - 10.0.31.190-10.0.31.254
    <strong>az: z1</strong>
    cloud_properties:
      security_groups:
      - <strong>sample-<%= vars.app_runtime_abbr_lc %>-is</strong>
      # with bbl, there is also a cf internal security group
      subnet: <strong>sample-subnet-<%= vars.app_runtime_abbr_lc %>-az1</strong>
  - range: 10.1.16.0/20
    gateway: 10.1.16.1
    reserved:
    - 10.1.16.2-10.1.16.3
    - 10.1.31.255
    static:
    - 10.1.31.190-10.1.31.254
    <strong>az: z2</strong>
    cloud_properties:
      security_groups:
      - <strong>sample-<%= vars.app_runtime_abbr_lc %>-is</strong>
      # with bbl, there is also be a cf internal security group
      subnet: <strong>sample-subnet-<%= vars.app_runtime_abbr_lc %>-az2</strong>
  - range: 10.0.200.0/28
    gateway: 10.0.200.1
    reserved:
    - 10.0.200.2-10.0.200.3
    - 10.0.200.15
    static:
    - 10.0.200.11-10.0.200.15
    <strong>az: z3</strong>
    cloud_properties:
      security_groups:
      - <strong>sample-is1</strong>
      subnet: <strong>sample-subnet-is1-az1</strong>
  - range: 10.1.200.0/28
    gateway: 10.1.200.1
    reserved:
    - 10.1.200.2-10.1.200.3
    - 10.1.200.15
    static:
    - 10.1.200.11-10.1.200.15
    <strong>az: z4</strong>
    cloud_properties:
      security_groups:
      - <strong>sample-is1</strong>
      subnet: <strong>sample-subnet-is1-az2</strong>
```


<% else %>
<%= vars.pcf_networking_is1 %>
<% end %>


## <a id='config-instance-group'></a> Step 3: Configure additional Gorouters

<% if vars.platform_code == 'CF' %>
You must edit the BOSH deployment manifest to include an instance group for each set of Gorouters.

The sample BOSH manifest snippet has an additional instance group for the isolated Gorouters, associated with the isolated BOSH AZs. As a result, Gorouter instances are configured with IP addresses from the isolated subnets. For more information about BOSH manifests, see [Deployment Config](https://bosh.io/docs/manifest-v2.html) in the BOSH documentation.

<p> For a high-availability deployment, assign each instance group to at least two BOSH AZs that correspond to different IaaS AZs. Use at
least two instances of each instance group.</p>

<p> When you deploy with a BOSH v2-style manifest that leverages <code>instance_groups</code>, you must enable UAA to
differentiate between links exported by the Gorouters, as it only accepts connections from one instance group of Gorouters.
As you can have multiple isolation segments, <%= vars.company_name %> recommends renaming the instance group used for the system domain.
You must also to specify the name of the link from which UAA consumes the link.</p>

```
instance_groups:
- name: router
  instances: 2
  azs: [z1,z2]
  networks:
  - name: default
  jobs:
  - name: gorouter
    provides:
      gorouter: {as: router_primary}
- name: uaa
  jobs:
  - name: uaa
    consumes:
      router: {from: router_primary}
- name: router-is1
  instances: 2
  azs: [z3,z4]
  networks:
  - name: default
- name: cell-is1
  instances: 2
  azs: [z3,z4]
  networks:
  - name: default
```

<% else %>
<%= vars.pcf_networking_is2 %>
<% end %>


## <a id='add-routers'></a> Step 4: Add Gorouters to load balancer

<% if vars.platform_code == 'CF' %>
For some IaaSes such as AWS and GCP, the BOSH cloud config and deployment manifest can be used to instruct BOSH to add Gorouters to the IaaS load balancers automatically. For others, operators must assign static IPs to the Gorouters in the manifest and assign these IPs to the load balancers out of band.

To automatically add load balancers to Gorouters, the `vm_extensions` property is available in BOSH manifests. For example:

```
instance_groups:
- name: router-is1
  instances: 2
  azs: [z3,z4]
  networks:
  - name: default
  vm_extensions:
  - cf-router-sample-is1-network-properties
```

The `vm_extension` is IaaS-specific and defined in the cloud config. This is an example AWS cloud config:

```
vm_extensions:
- name: cf-router-sample-is1-network-properties
  elbs: [sample-is1-elb]
  security_groups:
    - sample-is1
    - cf-router-lb-security-group # to allow traffic to the load balancer
```

<p> The load balancer <code>sample-is1-elb</code> must be created separately.</p>

<p> If necessary, configure a firewall rule to allow traffic from your load balancer to the Gorouters.</p>


<% else %>
<%= vars.pcf_networking_is3 %>
<% end %>


## <a id='config-dns-lb'> </a> Step 5: Configure DNS and load balancers

Create a separate domain name for each Gorouter instance group, and configure DNS to resolve these domain names to a load balancer that routes requests to the matching Gorouters.

<p> You must configure your load balancers to forward requests for a given domain to one Gorouter instance group only.</p>

As Gorouter instance groups might be responsible for separate isolation segments, and an app might be deployed to only one isolation segment, requests can only reach a Gorouter that has access to the apps for that domain name. Load balancing requests for a domain across more than Gorouter instance group can result in request failures unless all the Gorouter instance groups have access to the isolation segments where apps for that domain are deployed.

### <a id='sharing-domain'></a> Shared domain name

It is a common requirement for apps on separate isolation segments to be accessible at domain names that share a domain. For example, `private-domain.com`. To achieve this configuration while also obeying the guideline for forwarding requests for a domain to only one Gorouter instance group, create a new <%= vars.app_runtime_abbr %> domain for a needed subdomain, such as `*.foo.private-domain.com.`

The diagrams illustrate a topology with separate load balancers, but you could also use one load balancer with multiple interfaces.

In this configuration:

* Requests for system domain `*.cf-system.com` and the shared domain `*.shared-apps.com` are forwarded to the Gorouters for the <%= vars.app_runtime_abbr %> Diego Cells.

* Requests for private domain `*.foo.private-domain.com` are forwarded to the Gorouters for IS1. Requests for private domain `*.private-domain.com` are forwarded to the Gorouters for IS2.

![alt-text="Diagram showing an example shared domain."](./images/is-sharing-domains.png)

The example has three isolation segments and three Gorouters. See the following long description.") %>

The three isolation segments each use separate Gorouters and load balancers.

## <a id='config-firewall'></a> Step 6: Configure firewall rules

Configure firewall rules to allow for necessary ingress and egress traffic for isolation segments and <%= vars.app_runtime_abbr %> Diego Cells. Assuming a default deny-all rule, properly configuring firewall rules prevents a request with a spoofed Host header from being forwarded by a Gorouter to an app in a different isolation segment.

Firewall rules are specific to each IaaS, so the exact definition of `Source` and `Destination` depends on the IaaS. For example:
* On GCP, a `Source` is a subnet and a `Destination` is a tag.
* On AWS, both `Source` and `Destination` are security groups.

To configure firewall rules for isolation segment traffic:

1. Configure the firewall rules in the table below:

    For information about the processes that use these ports and their corresponding manifest properties, see
    <a href="#port-reference">Port Reference Table</a>.
    <table class="table">
      <thead>
      <tr>
        <th width="20%">Rule Name</th>
        <th width="20%">Source</th>
        <th width="20%">Allowed Protocols/Ports</th>
        <th width="20%">Destination</th>
        <th width="20%">Reason</th>
      </tr>
      </thead>
      <tr>
        <td><code><%= vars.app_runtime_abbr_lc %>-to-bosh</code></td>
        <td><%= vars.app_runtime_abbr %> Diego Cells</td>
        <td><code>tcp:4222, 25250, 25777</code></td>
        <td>BOSH Director</td>
        <td>BOSH Agent on VMs in the <%= vars.app_runtime_abbr %> Diego Cells to reach BOSH Director</td>
      </tr>
      <tr>
        <td><code><%= vars.app_runtime_abbr_lc %>-internal</code></td>
        <td><%= vars.app_runtime_abbr %> Diego Cells</td>
        <td><code>tcp:any, udp:any, icmp:any</code></td>
        <td><%= vars.app_runtime_abbr %> Diego Cells</td>
        <td>VMs within the <%= vars.app_runtime_abbr %> Diego Cells to reach one another</td>
      </tr>
      <tr>
        <td><code><%= vars.app_runtime_abbr_lc %>-to-is1</code></td>
        <td><%= vars.app_runtime_abbr %> Diego Cells</td>
        <td><code>tcp:1801, 8853, 53035</code></td>
        <td>Isolation segment</td>
        <td>Diego BBS in <%= vars.app_runtime_abbr %> Diego Cells to reach Diego Cells in isolation segment</td>
      </tr>
      <tr>
        <td><code>is1-to-bosh</code></td>
        <td>Isolation segment</td>
        <td><code>tcp:4222, 25250, 25777</code></td>
        <td>BOSH Director</td>
        <td>BOSH Agent on VMs in isolation segment to reach BOSH Director</td>
      </tr>
      <tr>
        <td><code>is1-internal</code></td>
        <td>Isolation segment</td>
        <td><code>tcp:all, udp:all, icmp:all</code></td>
        <td>Isolation segment</td>
        <td>VMs within isolation segment to reach one another</td>
      </tr>
      <tr>
        <td><code>is1-to-<%= vars.app_runtime_abbr_lc %></code></td>
        <td>Isolation segment</td>
        <td><code>tcp:3000, 3001, 4003, 4103, 4222, 4224, 4443, 6067, 8080, 8082, 8083, 8443, 8447, 8844, 8853, 8889, 8891, 9000, 9022, 9023, 9090, 9091</code></td>
        <td><%= vars.app_runtime_abbr %> Diego Cells</td>
        <td>Diego Cells in isolation segment to reach Diego BBS, Diego Auctioneer, and CredHub in <%= vars.app_runtime_abbr %>. Loggregator Agent to reach Doppler. Syslog Agent to reach Log Cache Syslog Server. Gorouters to reach NATS, UAA, and Routing API. Metrics Discovery Registrar to reach NATS.</td>
      </tr>
    </table>

1. (Optional) Configure the firewall rules in the following table:

    <table class="table">
      <thead>
      <tr>
        <th width="20%">Rule Name</th>
        <th width="20%">Source</th>
        <th width="20%">Allowed Protocols/Ports</th>
        <th width="20%">Destination</th>
        <th width="20%">Reason</th>
      </tr>
      </thead>
      <tr>
        <td><code>jumpbox-to-is1</code></td>
        <td>Jumpbox VM</td>
        <td><code>tcp:22</code></td>
        <td>Isolation segment</td>
        <td>Jumpbox VMs to reach isolation segment through SSH or BOSH SSH.</td>
      </tr>
      <tr>
        <td><code>diego-cell-egress</code></td>
        <td>Diego Cell VM on isolation segment</td>
        <td><code>tcp:any, udp:any</code></td>
        <td>Internet</td>
        <td>If Diego Cells must download buildpacks to stage apps, allow egress traffic from all Diego Cell VMs on isolation segments to reach the Internet.</td>
      </tr>
    </table>

Additional firewall rules might be necessary to allow logs to egress to application syslog drains. Connections for syslog drains are initiated both from Diego Cells and
Routers.

For more information about ports used by agents to communicate with BOSH, see the [bosh-deployment](https://github.com/cloudfoundry/bosh-deployment) repository on GitHub.

For more information about networks and firewall rules for GCP, see [Using Subnetworks](https://cloud.google.com/compute/docs/subnetworks) in the GCP documentation.

### <a id='port-reference'></a> Port Reference Table

To understand which protocols and ports map to which processes and manifest properties for the preceding rules, see the following table:

<table class="table">
<thead>
<tr>
  <th>Protocol</th>
  <th width="80px">Port</th>
  <th>Process</th>
  <th>Manifest Property</th>
</tr>
</thead>
<tr>
  <td><code>tcp</code></td>
  <td><code>1801</code></td>
  <td>Diego Rep</td>
  <td><code>diego.rep.listen_addr_securable</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>3000</code></td>
  <td>Routing API</td>
  <td><code>routing_api.port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>3001</code></td>
  <td>Routing API</td>
  <td><code>routing_api.mtls_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>4003</code></td>
  <td>VXLAN Policy Agent</td>
  <td><code>cf_networking.policy_server.internal_listen_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>4103</code></td>
  <td>Silk Controller</td>
  <td><code>cf_networking.silk_controller.listen_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>4222</code></td>
  <td>NATS</td>
  <td><code>nats.nats.port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>4224</code></td>
  <td>NATS</td>
  <td><code>nats-tls.nats.port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>4443</code></td>
  <td>CAPI Blobstore Port - HTTPS</td>
  <td><code>capi.blobstore.tls.port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>6067</code></td>
  <td>Log Cache Syslog Server</td>
  <td><code>log-cache.log-cache-syslog-server.syslog_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8080</code></td>
  <td>CAPI Blobstore Port - HTTP, Diego file server - HTTP</td>
  <td><code>capi.blobstore.port, diego.file_server.listen_addr</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8082</code></td>
  <td>Doppler gRPC, Reverse Log Proxy Gateway</td>
  <td><code>loggregator.doppler.grpc_port, loggregator.reverse_log_proxy.egress.port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8083</code></td>
  <td>Log Cache cf-auth-proxy</td>
  <td><code>log-cache.log-cache-cf-auth-proxy.proxy_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8084</code></td>
  <td>Diego file server - HTTP</td>
  <td><code>diego.file_server.listen_addr</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8443</code></td>
  <td>UAA</td>
  <td><code>uaa.uaa.ssl.port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8447</code></td>
  <td>Diego file server - HTTPS</td>
  <td><code>diego.file_server.https_listen_addr</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8844</code></td>
  <td>CredHub</td>
  <td><code>credhub.credhub.port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8853</code></td>
  <td>BOSH DNS health</td>
  <td><code>health.server.port</code> from <code>bosh-dns-release</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8889</code></td>
  <td>Diego BBS</td>
  <td><code>diego.rep.bbs.api_location</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>8891</code></td>
  <td>Diego Database (Locket)</td>
  <td><code>diego.locket.listen_addr</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>9000</code></td>
  <td>Loggregator Syslog Binding Cache</td>
  <td><code>loggr-syslog-binding-cache.external_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>9022</code></td>
  <td>Cloud Controller Stager</td>
  <td><code>capi.stager.cc.external_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>9023</code></td>
  <td>Cloud Controller TPS</td>
  <td><code>capi.tps.cc.external_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>9090</code></td>
  <td>Cloud Controller Uploader</td>
  <td><code>capi.cc_uploader.http_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>9091</code></td>
  <td>Cloud Controller Uploader</td>
  <td><code>capi.cc_uploader.https_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>53035</code></td>
  <td>System Metrics Scraper</td>
  <td><code>system-metrics-scraper.loggr-system-metric-scraper.scrape_port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>25250</code></td>
  <td>BOSH Blobstore</td>
  <td><code>bosh.blobstore.port</code></td>
</tr>
<tr>
  <td><code>tcp</code></td>
  <td><code>25777</code></td>
  <td>BOSH Registry</td>
  <td><code>bosh.registry.port</code></td>
</tr>
</table>


## <a id='gcp-implementation'></a> Additional GCP information

For more information, see [Understanding backend services](https://cloud.google.com/compute/docs/load-balancing/http/backend-service) in the GCP documentation and the [BOSH Google CPI Release](https://github.com/cloudfoundry-incubator/bosh-google-cpi-release/tree/master/src/bosh-google-cpi) repository on GitHub.


## <a id='sharding-routers-isolation-segment'></a> Sharding Gorouters for isolation segments

<% if vars.platform_code == 'CF' %>
To provide security guarantees in addition to the firewall rules previously described, an operator can configure sharding of the Gorouter's routing table, resulting in a Gorouter dedicated for an isolation segment having knowledge only of routes for apps in the same isolation segment. The flexibility of the configuration also supports deployment of a Gorouter that is responsible for multiple isolation segments, or that excludes all isolation segments.

### Bypass Cloud Controller Bridge

Support for Gorouter sharding depends on bypassing the Cloud Controller Bridge (CC Bridge), which is now the default behavior of [cf-deployment](https://github.com/cloudfoundry/cf-deployment). To manually bypass the CC bridge, set `cc.diego.temporary_local_apps: true` in your `cloud_controller_ng`, `cloud_controller_worker`, and `cloud_controller_clock` jobs in your deployment manifest. This enables the Cloud Controller to send app creation requests containing routing isolation segment information directly to the Diego BBS, rather than through the CC Bridge.

For more information about the CC Bridge, see [Diego Components and Architecture](../concepts/diego/diego-architecture.html).

### Configure Gorouters for sharding

You can configure Gorouters for sharding using two manifest properties, `routing_table_sharding_mode` and `isolation_segments`.

The three supported values of `routing_table_sharding_mode` are `all`, `<%= vars.app_runtime_abbr_lc %>-and-segments`, and `segments`.

* `all`: All routes are registered. This is the default mode to preserve the Gorouter's existing behavior.

* `<%= vars.app_runtime_abbr_lc %>-and-segments`: Both routes configured with manifest property `isolation_segments` and routes without an isolation segment specified are registered.

* `segments`: Only routes for the configured isolation segments are registered.

You can provide a list of isolation segments using the manifest property `isolation_segments`.

The following table describes the behaviors that you can achieve with these two properties:

| Sharding Mode | Isolation Segments | Routes Registered |
| ------------- | ------------------ | ----------------- |
| `all` | `none` | All routes. |
| `all` | `provided` | All routes. |
| `<%= vars.app_runtime_abbr_lc %>-and-segments` | `none` | Routes that are not associated with an isolation segment. |
| `<%= vars.app_runtime_abbr_lc %>-and-segments` | `provided` | Routes that are not associated with an isolation segment, as well as routes for the specified isolation segments. Routes for other isolation segment are excluded. |
| `segments` | `none` | Invalid combination. Deploy fails. |
| `segments` | `provided` | Routes for specified isolation segments only. |

For example, the following configuration in a deployment manifest describes a deployment with one Gorouter in the <%= vars.app_runtime_abbr %> Diego Cells and another Gorouter in a separate isolation segment `is1`:

```
jobs:
- name: router_<%= vars.app_runtime_abbr_lc %>
  properties:
    router:
      isolation_segments: []
      routing_table_sharding_mode: <%= vars.app_runtime_abbr_lc %>-and-segments
...
- name: router_is1
  properties:
    router:
      isolation_segments:
      - is1
      routing_table_sharding_mode: segments

```

The `router_<%= vars.app_runtime_abbr_lc %>` Gorouter registers all routes that do not have an `isolation_segment` value. The `router_is1` Gorouter only registers routes that have an `isolation_segment` value of `is1`.

<% else %>

<%= partial "/pcf/core/pcf_sharding" %>

<% end %>


## <a id='isolation-segments-metrics'></a> Metrics for Gorouters associated with isolation segments

For metrics emitted by the Gorouter, metrics can be distinguished by the name of the job. For example, this line is a metric emitted on `uptime`:

```
origin:"gorouter" eventType:ValueMetric timestamp:1491338040750977602 deployment:"superman.cf-app.com" job:"router_is1" index:"9a4b639c-8f0e-4b2b-b332-4161ee4646e6" ip:"10.0.16.23" valueMetric:<name:"uptime" value:118 unit:"seconds" >
```