anchor.diff:    - name: private
   </code>
   </pre>
  -<% else %>
  -<%= vars.config_networking_is %>
  -<% end %>
  -
  -##<a id='config-firewall'></a> Step 3: Configure Firewall Rules
  -
  -Configure firewall rules to allow necessary traffic between the shared isolation segments (`sample-shared-is`) and the private isolation segments (`sample-is1` and `sample-is2`). Assuming a default deny-all rule, these rules should prevent a request with a spoofed Host header from being forwarded by a router to an application in another isolation segment.
  -
  -<table>
  -<tr>
  -<th>Rule Name</th>
  -<th>Source subnetwork</th>
  -<th>Allowed Protocols/Ports</th>
  -<th>Target Tags</th>
  -<th>Reason</th>
  -</tr>
  -<tr>
  -<td><code>shared-to-bosh</code></td>
  -<td><code>sample-subnet-shared</code></td>
  -<td><code>tcp:22,6868,25555,<br>4222,25250<code></td>
  -<td><code>sample-bosh</code></td>
  -<td>BOSH Agent on VMs in <code>sample-shared-is</code> to reach BOSH Director</td>
  -</tr>
  -<tr>
  -<td><code>shared-internal</code></td>
  -<td><code>sample-subnet-shared</code></td>
  -<td><code>tcp</code></td>
  -<td><code>sample-shared-is</code></td>
  -<td>VMs within <code>sample-shared-is</code> to reach one another</td>
  -</tr>
  -<tr>
  -<td><code>shared-to-is1</code></td>
  -<td><code>sample-subnet-shared</code></td>
  -<td><code>tcp:1801</code></td>
  -<td><code>sample-is1</code></td>
  -<td>Diego BBS in <code>sample-shared-is</code> to reach Cells in <code>sample-is1</code></td>
  -</tr>
  -<tr>
  -<td><code>shared-to-is2</code></td>
  -<td><code>sample-subnet-shared</code></td>
  -<td><code>tcp:1801</code></td>
  -<td><code>sample-is2</code></td>
  -<td>Diego BBS in <code>sample-shared-is</code> to reach Cells in <code>sample-is2</code></td>
  -</tr>
  -<tr>
  -<td><code>is1-to-bosh</code></td>
  -<td><code>sample-subnet-is1</code></td>
  -<td><code>tcp:22,6868,25555,<br>4222,25250</code></td>
  -<td><code>sample-bosh</code></td>
  -<td>BOSH agent on VMs in <code>sample-is1</code> to reach BOSH Director</td>
  -</tr>
  -<tr>
  -<td><code>is1-internal</code></td>
  -<td><code>sample-subnet-is1</code></td>
  -<td><code>tcp</code></td>
  -<td><code>sample-is1</code></td>
  -<td>VMs within <code>sample-is1</code> to reach one another</td>
  -</tr>
  -<tr>
  -<td><code>is1-to-shared</code></td>
  -<td><code>sample-subnet-is1</code></td>
  -<td><code>tcp:8300-8500,8889,4443,9016,<br>8080,9090,3457,9022</code></td>
  -<td><code>sample-shared-is</code></td>
  -<td>Diego Cells in <code>sample-is1</code> to reach BBS and Auctioneer in <code>sample-shared-is</code>, Consul Agent to reach Consul, Metron Agent to reach Traffic Controller, and Routers to reach NATS, UAA, and Routing API</td>
  -</tr>
  -<tr>
  -<td><code>is2-to-bosh</code></td>
  -<td><code>sample-subnet-is2</code></td>
  -<td><code>tcp:22,6868,25555,<br>4222,25250</code></td>
  -<td><code>sample-bosh</code></td>
  -<td>BOSH agent on VMs in <code>sample-is2</code> to reach BOSH Director</td>
  -</tr>
  -<tr>
  -<td><code>is2-internal</code></td>
  -<td><code>sample-subnet-is2</code></td>
  -<td><code>tcp</code></td>
  -<td><code>sample-is2</code></td>
  -<td>VMs within <code>sample-is2</code> to reach one another</td>
  -</tr>
  -<tr>
  -<td><code>is2-to-shared</code></td>
  -<td><code>sample-subnet-is2</code></td>
  -<td><code>tcp:8300-8500,8889,4443,<br>9016,8080,9090,3457,9022</code></td>
  -<td><code>sample-shared-is</code></td>
  -<td>Diego Cells in <code>sample-is2</code> to reach BBS and Auctioneer in <code>sample-shared-is</code>, Consul Agent to reach Consul, Metron Agent to reach Traffic Controller, and Routers to reach NATS, UAA, and Routing API</td>
  -</tr>
  -</table>
  -
  -For more information consult the following topics:
  -
  -* The `bosh-deployment` GitHub [repo](https://github.com/cloudfoundry/bosh-deployment) contains documentation describing ports used by agents to communicate with BOSH.
  -* The "Using Subnetworks" topic in the GCP [documentation](https://cloud.google.com/compute/docs/subnetworks) describes networks and firewall rules in the "Isolation of Subnetworks" section.
  -
  -## <a id='config-dns-lb'></a>Step 4: Configure DNS and Load Balancers
  -
  -Create a separate domain name for each router group, and configure DNS to resolve these domain names to a load balancer that routes requests to the matching router groups. 
  -
  -<p class="note"><strong>Note</strong>: You must configure your load balancers to forward requests for a given domain to one router group only.</p>
  -
  -As router 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.
  -
  -The sections below describe a configuration that routes applications from [distinct domain names](#distinct-domain), and a configuration that routes applications from a [shared domain name](#sharing-domain). The diagrams illustrate a topology with separate load balancers, but you could also use one load balancer with multiple interfaces.
  -
  -### <a id='distinct-domain'></a>Distinct Domain Names
  -
  -In a configuration that routes applications from distinct domain names:
  -
  -* Requests for system domain `*.cf-system.com` and the shared domain `*.cf-apps.com` are forwarded to the routers for the shared isolation segment.
  -* Requests for private domain `*.private-domain.com` are forwarded to the routers for IS1.
  -
  -<%= image_tag('is-distinct-domains.png') %>
  -
  -### <a id='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-apps.com`. To achieve this configuration while also obeying the guideline for forwarding requests for a domain to only one router group, create a new Cloud Foundry domain for a needed subdomain, such as `*.foo.private-apps.com.`
  -
  -In this configuration: 
  -
  -* Requests for system domain `*.cf-system.com` and the shared domain `*.cf-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 id='gcp-implementation'></a> Additional GCP Information
  -
  -When deploying dedicated routers for isolation segments on GCP, consider:
  -
  -* The routers for each isolation segment are represented by instance groups, which are associated with load balancers by configuring a backend service which describes the load balancer rules. In the following example, the `vm_extension` called `cf-router-network-properties` is defined in the cloud config with a GCP backend service.
  +
  +## <a id='add-routers'></a>Step 4: Add Routers to Load Balancer
  +
  +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.
  +
  +For deployments to GCP, associate the router instance groups with load balancers by first configuring a backend service which describes the load balancer rules. Next, define the backend service in the Cloud Config with a `vm_extension`. Finally, associate the router instance groups with the `vm_extention`. In the following example, the `vm_extension` called `cf-router-network-properties` is defined in the cloud config with a GCP backend service.
     
     ```
     instance_groups:
  
positive.code: 
  <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 called a router group to handle requests for applications within the segment.
  
  For more information about how isolation segments work, see the [Isolation Segments](../concepts/security.html#isolation-segments) section of the <em>Understanding Cloud Foundry Security</em> topic. <%= vars.install_isolation_segments %>
  
  
negative.code: </code>
  </pre>
  
  ##<a id='config-instance-group'></a> Step 3: Configure Additional Routers
  
  You must edit the BOSH deployment manifest to include an instance group for each set of routers.
  
  The sample [BOSH v2 manifest](https://bosh.io/docs/manifest-v2.html) snippet below includes additional instance groups for the routers of each isolation segment, each associated with different BOSH AZs. As a result, a router instances will be configured with IP addresses from different subnets. 
  
  <p class="note"><strong>Note</strong>: For a high-availability deployment assign each subnet to at least two AZs, use at least two instances of each instance group, and assign each instance group to at least two BOSH AZs. .</p>
  
  