anchor.diff:  }
   ----
   
  -Note that while both secure and unsecure is possible with an OpenShift deployment, Red Hat recommends a secure routing service for a more secure deployment.
  +====
  +
  +Note that while both secure and unsecure is possible with an OpenShift deployment, Red Hat recommends a secure routing service.
   
   == Securing Routes
  -Creating a secure route to your pods can be accomplished by specifying the TLS Termination of the route and, optionally, providing certificates to use. As of writing, OpenShift beta1 TLS termination relies on SNI for serving custom certificates (in the reference HAProxy implementation). Any non-SNI traffic received on port 443 will have TLS terminated with a generic certificate. In the future, the ability to create custom frontends within the router will allow all traffic to serve custom certificates.
  -
  -There are three types of TLS termination:
  +Creating a secure route to your pods is accomplished by specifying the TLS Termination of the route and, optionally, providing certificates. At the time of writing, OpenShift Beta 1 TLS termination relies on SNI for serving custom certificates. Any non-SNI traffic received on port 443 has TLS termination with a generic certificate. In the future, the ability to create custom frontends within the router will allow all traffic to serve custom certificates.
  +
  +By default, OpenShift has no pod encryption, but can be set to any of the following three types of TLS termination:
   
   === Edge Termination
  -Edge termination means that TLS termination occurs prior to traffic reaching the destination. TLS certificates are served by the frontend of the router.
  -
  -Edge termination is configured by setting `TLS.Termination` to edge on your route and by specifying the `CACertificatFile`, `CertificateFile` and `KeyFile`.
  +Edge termination is when TLS termination occurs prior to traffic reaching its destination. TLS certificates are served by the front end of the router.
  +
  +Edge termination is configured by setting `tls:termination` to `edge` on your route and by specifying the `certificate`, `caCertificate`, and `key`:
   
   ----
   {
  
positive.code: 
  == HA Routers
  
  Highly available router setups can be accomplished by running multiple instances of the router pod and fronting them with a balancing tier. This could be something as simple as DNS round robin or as complex as multiple load balancing layers.
  
  === DNS Round Robin
  
  As a simple example, you may create a zone file for a DNS server like BIND that maps multiple A records for a single domain name. When clients do a lookup they will be given one of the many records, in order, as a round robin scheme. The files below illustrate an example of using wild card DNS with multiple A records to achieve the desired round robin. The wild card could be further distributed into shards with `*.<shard>`. Finally, a test using `dig` (available in the `bind-utils` package) is shown from the vagrant environment that shows multiple answers for the same lookup. Doing multiple pings show the resolution swapping between IP addresses.
  
  
  
  ----
  #### named.conf - add a new zone that points to your file
      zone "v3.rhcloud.com" IN {
              type master;
              file "v3.rhcloud.com.zone";
      };
  
  
  #### v3.rhcloud.com.zone - contains the round robin mappings for the DNS lookup
      $ORIGIN v3.rhcloud.com.
  
      @       IN      SOA     . v3.rhcloud.com. (
  
negative.code:     *       IN      A       10.245.2.2
              IN      A       10.245.2.3
  
  
  ----
  Testing the entry:
  ----
  
      [vagrant@openshift-master ~]$ dig hello-openshift.shard1.v3.rhcloud.com
  
  