routing-is.html.md.erb

---
title: Routing for Isolation Segments
owner: Routing
---

<strong><%= modified_date %></strong>

This topic describes how operators can configure and manage routing for isolation segments. Operators can deploy an additional set of routers for each isolation segment to handle requests for applications within the segment. This topic includes the following sections:

* <a href="#overview">Overview</a></td>
* <a href="#create-networks">Step 1: Create Networks</a></td>
* <a href="#config-networks">Step 2: Configure Networks for Routers</a></td>
* <a href="#config-instance-group">Step 3: Configure Additional Routers</a></td>
* <a href="#add-router">Step 4: Add Routers to Load Balancers</a></td>
* <a href="#config-dns-lb">Step 5: Configure DNS and Load Balancers</a></td>
* <a href="#config-firewall">Step 6: Configure Firewall Rules</a></td>
* <a href="#gcp-implementation">Additional GCP Information</a></td>
* <a href="#sharding-routers-isolation-segment">Sharding Routers for Isolation Segments</a></td>
* <a href="#isolation-segments-metrics">Metrics for Routers Associated with Isolation</a></td>


For more information about how isolation segments work, see the [Isolation Segments](../concepts/security.html#isolation-segments) section of the <em>Cloud Foundry Security</em> topic. <%= vars.install_isolation_segments %>

<p class="note"><strong>Note</strong>: The instructions in this topic assume you are using Google Cloud Platform (GCP). The procedures may differ on other IaaSes, but the concepts should be transferable.</p>

## <a name='overview'></a>Overview

Isolation segments isolate the compute resources for one group of applications from another. However, these applications still share the same network resources. Requests for applications on all isolation segments, as well as for system components, transit the same load balancers and Cloud Foundry routers.

A shared 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 illustration below shows isolation segments sharing the same network resources.

<%= image_tag('routing-is.png') %>

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

<%= image_tag('is-distinct-domains.png') %>

Use cases include:

* Requests for applications in an isolation segment must not share networking resources with requests for other applications.
* The Cloud Foundry management plane should only be accessible from a private network. As multiple IaaS load balancers cannot typically share the same pool of backends, such as Cloud Foundry routers, each load balancer requires an additional deployment of routers.

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

### Create a network or subnet for each isolation segment on your infrastructure

As an example, an operator who wants one shared isolation segment and one private segment could create one network named `sample-network` with two subnets named `sample-subnet-shared`, `sample-subnet-is1`.

The following diagram describes the network topology:

```
IaaS network: sample-network
  |
  |_____ IaaS subnet: sample-subnet-shared
  |
  |_____ IaaS subnet: sample-subnet-is1
```

Subnets do not generally span IaaS availability zones, so the same operator with two availability zones will need four subnets

```
IaaS network: sample-network
|
|_____ IaaS subnet: sample-subnet-shared-az1
|
|_____ IaaS subnet: sample-subnet-shared-az2
|
|_____ IaaS subnet: sample-subnet-is1-az1
|
|_____ IaaS subnet: sample-subnet-is1-az2

```

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


##<a name='config-networks'></a> Step 2: Configure Networks for Routers

To configure the subnets with Bosh, use [Bosh Cloud Config](https://bosh.io/docs/cloud-config.html) subnets. Each subnet in the IaaS should correspond to a Bosh subnet that is labeled with the correct isolation segment

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

Below are examples of cloud config for GCP and AWS for the [four example subnets](#create-networks) described above.

### GCP Cloud Config

<pre><code>
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-shared-az1</strong>
      tags:
      - <strong>sample-shared-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-shared-az2</strong>
      tags:
      - <strong>sample-shared-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>
</code>
</pre>

### AWS Cloud Config
<p class="note"><strong>Note</strong>: AWS networking requires security groups, which need to be created separately. In the below example, the operator will need to create the <strong>sample-shared-is</strong> and <strong>sample-is1</strong> security groups. </p>

<pre>
<code>
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-shared-is</strong>
      # with bbl, there will also be a cf internal security group
      subnet: <strong>sample-subnet-shared-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-shared-is</strong>
      # with bbl, there will also be a cf internal security group
      subnet: <strong>sample-subnet-shared-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>
</code>
</pre>


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

##<a name='config-instance-group'></a> Step 3: Configure Additional Routers

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

The sample [BOSH manifest](https://bosh.io/docs/manifest-v2.html) snippet below includes an additional instance group for the isolated routers, associated with the isolated BOSH AZs. As a result, router instances will be configured with IP addresses from the isolated subnets.

<p class="note"><strong>Note</strong>: 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 class="note"><strong>Note</strong>: When deploying 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 will only accept connections from one instance group of Gorouters. As you may have multiple isolation segments, we recommend renaming the instance group used for the system domain. You will also need to specify the name of the link that UAA consumes the link from.</p>

<pre><code>
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

</code>
</pre>

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

## <a name='add-routers'></a>Step 4: Add Routers to Load Balancer

<% if vars.product_name == 'CF' %>
For some IaaS (e.g. AWS, GCP), the BOSH Cloud Config and deployment manifest can be used to instruct BOSH to add routers to the IaaS load balancers automatically. For others, operators must assign static IPs to the routers in the manifest and assign these IPs to the load balancers out of band.

To automatically add load balancers to routers, 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 Cloud Config. Below 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 class="note"><strong>Note</strong>: The load balancer <code>sample-is1-elb</code> must be created separately.</p>

<p class="note"><strong>Note</strong>: If necessary, configure a firewall rule to allow traffic from your load balancer to the Gorouters.</p>


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

## <a name='config-dns-lb'></a>Step 5: Configure DNS and Load Balancers

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

<p class="note"><strong>Note</strong>: You must configure your load balancers to forward requests for a given domain to one router instance group only.</p>

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

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

It is a common requirement for applications on separate isolation segments to be accessible at domain names that share a domain, such as `private-domain.com`. To achieve this configuration while also obeying the guideline for forwarding requests for a domain to only one router instance group, create a new Cloud Foundry 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 routers for the shared isolation segment.
* Requests for private domain `*.foo.private-domain.com` are forwarded to the routers for IS1.
Requests for private domain `*.private-domain.com` are forwarded to the routers for IS2.

<%= image_tag('is-sharing-domains.png') %>

##<a name='config-firewall'></a> Step 6: Configure Firewall Rules

Configure firewall rules to allow for necessary ingress and egress traffic for private and shared isolation segments. Assuming a default deny-all rule, properly configuring firewall rules prevents a request with a spoofed Host header from being forwarded by a router to an application in a different isolation segment.

To configure firewall rules for isolation segment traffic, do the following:

1. Configure the firewall rules in the table below: 
    
    <p class="note"><b>Note:</b> Firewall rules are specific to each IaaS, so the exact definition of <code>Source</code> and <code>Destination</code> depends on the IaaS. For example, on GCP, a <code>Source</code> is a subnet and a <code>Destination</code> is a tag. On AWS, both <code>Source</code> and <code>Destination</code> are security groups.</p>

    <table>
      <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>
      <tr> 
      <td><code>shared-to-bosh</code></td>
      <td>Shared isolation segment</td>
      <td><code>tcp</code></td>
      <td>BOSH Director</td>
      <td>BOSH Agent on VMs in the shared isolation segment to reach BOSH Director</td>
      </tr>
      <tr>
      <td><code>bosh-to-shared</code></td>
      <td>BOSH Director</td>
      <td><code>tcp</code></td>
      <td>Shared isolation segment</td>
      <td>BOSH director to control VMs in the shared isolation segment</td>
      </tr>
      <tr>
      <td><code>shared-internal</code></td>
      <td>Shared isolation segment</td>
      <td><code>tcp</code></td>
      <td>Shared isolation segment</td>
      <td>VMs within the shared isolation segment to reach one another</td>
      </tr>
      <tr>
      <td><code>shared-to-is1</code></td>
      <td>Shared isolation segment</td>
      <td><code>tcp:1801,8853</code></td>
      <td>Private isolation segment</td>
      <td>Diego BBS in shared isolation segment to reach Cells in private isolation segment</td>
      </tr>
      <tr>
      <td><code>is1-to-bosh</code></td>
      <td>Private isolation segment</td>
      <td><code>tcp:4222,25250,25777</code></td>
      <td>BOSH Director</td>
      <td>BOSH agent on VMs in private isolation segment to reach BOSH Director</td>
      </tr>
      <tr>
      <tr>
      <td><code>is1-internal</code></td>
      <td>Private isolation segment</td>
      <td><code>tcp</code></td>
      <td>Private isolation segment</td>
      <td>VMs within private isolation segment to reach one another</td>
      </tr>
      <tr>
      <td><code>is1-to-shared</code></td>
      <td>Private isolation segment</td>
      <td><code>tcp:3000,3457,4003<br>4103,4222,4443,8080<br>8082,8083,8443,8844
        <br>8853,8889,8891<br>9022,9023,9090,9091<br></code>
      <br><br>
      See <a href="#port-reference">Port Reference Table</a> for information about the processes that use these ports and their corresponding manifest properties.
      </td>
      <td>Shared isolation segment</td>
      <td>Diego Cells in private isolation segment to reach BBS, Auctioneer, and CredHub in shared isolation segment. Loggregator Agent to reach Traffic Controller. Routers to reach NATS, UAA, and Routing API</td>
      </tr>
    </table>

1. (Optional) Configure the firewall rules in the table below:
    
    <table>
      <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>
      <tr>
      <td><code>jumpbox-to-is1</code></td>
      <td>Jumpbox VM</td>
      <td><code>tcp:22</code></td>
      <td>Private isolation segment</td>
      <td>Jumpbox VMs to reach private isolation segment through SSH or BOSH SSH.</td>
      </tr>
      <tr>  
      <td><code>is1-to-jumpbox</code></td>
      <td>Private isolation segment</td>
      <td><code>tcp</code></td>
      <td>Jumpbox VM</td>
      <td>Private isolation segment to reach jumpbox VM. Opens reverse SSH or BOSH SSH tunnel from jumpbox VM to private isolation segment.</td>
      </tr>
      <tr>
      <td><code>diego-cell-egress</code></td>
      <td>Diego cell VM on private isolation segment</td>
      <td><code>tcp</code></td>
      <td>Internet</td>
      <td>If Diego Cells must download buildpacks to stage applications, allow egress traffic from all Diego Cell VMs on private isolation segments to reach the Internet.</td>
      </tr>
    </table>

For more information about ports used by agents to communicate with BOSH, see [bosh-deployment](https://github.com/cloudfoundry/bosh-deployment) in 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 name='port-reference'></a> Port Reference Table

See the following table to understand which protocols and ports map to which processes and manifest properties for the `is1-to-shared` rule above.

<table>
<tr>
<th>Protocol</th>
<th>Port</th>
<th>Process</th>
<th>Manifest Property</th>
</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>3457</code></td>
<td>Doppler</td>
<td><code>metron_endpoint.dropsonde_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>router.nats.port</code></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>8080</code></td>
<td>Diego file server</td>
<td><code>diego.file_server.listen_addr</code></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>8082</code></td>
<td>Doppler gRPC</td>
<td><code>loggregator.doppler.grpc_port</code></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>8300</code></td>
<td>Consul**</td>
<td></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>8301</code></td>
<td>Consul**</td>
<td></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>8302</code></td>
<td>Consul**</td>
<td></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>8443</code></td>
<td>UAA</td>
<td><code>uaa.ssl.port</code></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>8844</code></td>
<td>CredHub</td>
<td><code>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>9022</code></td>
<td>CC stager</td>
<td><code>capi.stager.cc.external_port</code></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>9023</code></td>
<td>CC TPS</td>
<td><code>capi.tps.cc.external_port</code></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>9090</code></td>
<td>CC uploader</td>
<td><code>http_port</code></td>
</tr>
<tr>
<td><code>tcp</code></td>
<td><code>9091</code></td>
<td>CC uploader</td>
<td><code>https_port</code></td>
</tr>
<tr>
<td><code>udp</code></td>
<td><code>8301</code></td>
<td>Consul**</td>
<td></td>
</tr>
<tr>
<td><code>udp</code></td>
<td><code>8302</code></td>
<td>Consul**</td>
<td></td>
</tr>
<tr>
<td><code>udp</code></td>
<td><code>8600</code></td>
<td>Consul**</td>
<td></td>
</tr>
</table>
** [Consul documentation: Ports Used](https://www.consul.io/docs/agent/options.html#ports-used)

## <a name='gcp-implementation'></a> Additional GCP Information

For more information, see the following:

* "Backend Services" in the GCP [documentation](https://cloud.google.com/compute/docs/load-balancing/http/backend-service)
* BOSH Google Compute Engine CPI GitHub [repository](https://github.com/cloudfoundry-incubator/bosh-google-cpi-release/tree/master/src/bosh-google-cpi)

## <a name='sharding-routers-isolation-segment'></a> Sharding Routers for Isolation Segments

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

### Bypass Cloud Controller Bridge

Support for router sharding depends on bypassing the [Cloud Controller Bridge](../concepts/diego/diego-architecture.html#bridge-components) (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.

### Configure Routers for Sharding

Configuration is achieved using two manifest properties, `routing_table_sharding_mode` and `isolation_segments`.

The three supported values of `routing_table_sharding_mode` are `all`, `shared-and-segments`, and `segments`.

* `all`: All routes will be registered. This is the default mode to preserve the Gorouter's existing behavior.
* `shared-and-segments`: Both routes configured with manifest property `isolation_segments` and routes without an isolation segment specified will be registered.
* `segments`: Only routes for the configured isolation segments will be 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:

<table>
<tr>
<th> Sharding Mode </th>
<th> Isolation Segments </th>
<th> Routes Registered </th>
</tr>
<tr>
<td> all </td>
<td> none </td>
<td> All routes </td>
</tr>
<tr>
<td> all </td>
<td> provided </td>
<td> All routes </td>
</tr>
<tr>
<td> shared-and-segments </td>
<td> none </td>
<td> Routes that are not associated with an isolation segment </td>
</tr>
<tr>
<td> shared-and-segments </td>
<td> provided </td>
<td> Routes that are not associated with an isolation segment, as well as routes for the specified isolation segments.
Routes for other isolation segment will be excluded. </td>
</tr>
<tr>
<td> segments </td>
<td> none </td>
<td> Invalid combination. Deploy will fail. </td>
</tr>
<tr>
<td> segments </td>
<td> provided </td>
<td> Routes for specified isolation segments only. </td>
</tr>
</table>

For example, the following configuration in a deployment manifest describes a deployment with one router in
the shared segment and another router in a separate isolation segment `is1`:

```
jobs:
- name: router_shared
  properties:
    router:
      isolation_segments: []
      routing_table_sharding_mode: shared-and-segments
...
- name: router_is1
  properties:
    router:
      isolation_segments:
      - is1
      routing_table_sharding_mode: segments

```

The `router_shared` router will register all routes that do not have an `isolation_segment` value.
The `router_is1` router will only register routes that have an `isolation_segment` value of `is1`.

<% else %>

<%= partial vars.sharding %>

<% end %>

##<a name='isolation-segments-metrics'></a>Metrics for Routers Associated with Isolation Segments

For metrics emitted by the Gorouter, metrics can be distinguished by the name of the job.
For example, the following 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" >
```