anchor.diff:  | Option | Variable Name | Default | Notes
   
   |`--watch-port`
  -|`*OPENSHIFT_HA_MONITOR_PORT*`
  +|`OPENSHIFT_HA_MONITOR_PORT`
   |80
   |The ipfailover pod tries to open a TCP connection to this port on each VIP. If connection is established, the service is considered to be running. If this port is set to 0, the test always passes.
   
   |`--interface`
  -|`*OPENSHIFT_HA_NETWORK_INTERFACE*`
  +|`OPENSHIFT_HA_NETWORK_INTERFACE`
   |
  -|The interface name for the ip failover to use, to send VRRP traffic. By default, `eth0` is used.
  +|The interface name for ipfailover to use, to send VRRP traffic. By default, `eth0` is used.
   
   |`--replicas`
  -|`*OPENSHIFT_HA_REPLICA_COUNT*`
  +|`OPENSHIFT_HA_REPLICA_COUNT`
   |2
  -|Number of replicas to create. This must match `spec.replicas` value in ipfailover deployment configration.
  +|Number of replicas to create. This must match `spec.replicas` value in ipfailover deployment configuration.
   
   |`--virtual-ips`
  -|`*OPENSHIFT_HA_VIRTUAL_IPS*`
  +|`OPENSHIFT_HA_VIRTUAL_IPS`
   |
  -|The list of IP address ranges to replicate. This must be provided. E.g., 1.2.3.4-6,1.2.3.9
  -Please see xref:../admin_guide/high_availability.adoc#ha-vrrp-id-offset[this discussion] for more details.
  +|The list of IP address ranges to replicate. This must be provided. (For example, 1.2.3.4-6,1.2.3.9.)
  +See xref:../admin_guide/high_availability.adoc#ha-vrrp-id-offset[this discussion] for more details.
   
   |`--vrrp-id-offset`
  -|`*OPENSHIFT_HA_VRRP_ID_OFFSET*`
  +|`OPENSHIFT_HA_VRRP_ID_OFFSET`
   |0
  -|Please see xref:../admin_guide/high_availability.adoc#ha-vrrp-id-offset[VRRP Id Offset] discussion for more details.
  +|See xref:../admin_guide/high_availability.adoc#ha-vrrp-id-offset[VRRP ID Offset] discussion for more details.
   
   |`--iptables-chain`
  -|`*OPENSHIFT_HA_IPTABLES_CHAIN*`
  +|`OPENSHIFT_HA_IPTABLES_CHAIN`
   |INPUT
   |The name of the iptables chain, to automatically add an `iptables` rule to allow the VRRP traffic on. If the value is not set, an `iptables` rule will not be added. If the chain does not exist, it is not created.
   
   |`--check-script`
  -|`*OPENSHIFT_HA_CHECK_SCRIPT*`
  +|`OPENSHIFT_HA_CHECK_SCRIPT`
   |
  -|Full path name in the pod filesystem of a script that will be periodically run to verify the application is operating.  Please see xref:../admin_guide/high_availability.adoc#check-notify[this discussion] for more details.
  +|Full path name in the pod file system of a script that is periodically run to verify the application is operating.  Please see xref:../admin_guide/high_availability.adoc#check-notify[this discussion] for more details.
   
   |`--check-interval`
  -|`*OPENSHIFT_HA_CHECK_INTERVAL*`
  +|`OPENSHIFT_HA_CHECK_INTERVAL`
   |2
  -|The period, in seconds that the check script is run.
  +|The period, in seconds, that the check script is run.
   
   |`--notify-script`
  -|`*OPENSHIFT_HA_NOTIFY_SCRIPT*`
  +|`OPENSHIFT_HA_NOTIFY_SCRIPT`
   |
  -|Full path name in the pod filesystem of a script that is run whenever the state changes.  Please see xref:../admin_guide/high_availability.adoc#check-notify[this discussion] for more details.
  +|Full path name in the pod file system of a script that is run whenever the state changes. See xref:../admin_guide/high_availability.adoc#check-notify[this discussion] for more details.
   
   |===
   
   [[ha-vrrp-id-offset]]
  -=== VRRP Id Offset
  +=== VRRP ID Offset
  +
   Each ipfailover pod managed by the ipfailover deployment configration (1 pod per node/replica) runs a *keepalived* daemon. As more ipfailover deployment configrations are configured, more pods are created and more daemons join into the common VRRP negotiation. This negotiation is done by all the *keepalived* daemons and it determines which nodes will service which VIPs.
   
   Internally, *keepalived* assigns a unique vrrp-id to each VIP. The negotiation uses this set of vrrp-ids, when a decision is made, the VIP corresponding to the winning vrrp-id is serviced on the winning node.
  
positive.code:     --mount-path=/etc/keepalive \
      --source='{"configMap": { "name": "mycustomcheck"}}'
  ----
  ====
  +
  Editing the Ipf-HA-Router Deployment Configuration::
  +
  Use `oc edit dc ipf-ha-router` to edit the router deployment configuration
  with a text editor.
  +
  ====
  [source,yaml]
  ----
  ...
  
negative.code: ====
  
  [[check-notify]]
  === Check and Notify Scripts
  
  The *keepalived* port monitoring feature supports one or two scripts that are
  run on a configured interval to verify that the application is available. The
  default script uses a simple
  xref:../install_config/install/prerequisites.adoc#required-ports[TCP
  connection] to verify that the application is running. This test is suppressed
  when the monitoring port is set to `0`. The administrator can supply an
  additional script that does the needed verification. For example, the script can
  test a web server by issuing a request and verifying the response. The script
  must exit with `0` for *PASS* and `1` for *FAIL*.
  
  The administrator provides the additional script, via the
  `--check-script=<script>` option. By default, the check is done every two
  seconds, but can be changed using the `--check-interval=<seconds>` option.
  
  For each VIP, *keepalived* keeps the state of the node. The VIP on the node may
  be in *MASTER*, *BACKUP*, or *FAULT* state. All VIPs on the node that are not in
  the *FAULT* state participate in the negotiation to decide which will be
  *MASTER* for the VIP. All of the losers enter the *BACKUP* state. When the
  *check* script on the *MASTER* fails, the VIP enters the *FAULT* state and
  triggers a renegotiation. When the *BACKUP* fails, the VIP enters the *FAULT*
  state. When the *check* script passes again on a VIP in the *FAULT* state, it
  exits *FAULT* and negotiates for *MASTER*. The resulting state is either
  *MASTER* or *BACKUP*.
  
  The administrator can provide an optional *notify* script, which is called
  whenever the state changes. *Keepalived* passes the following three parameters
  to the script:
  
  * `$1` - "GROUP"|"INSTANCE"
  * `$2` - Name of the group or instance
  * `$3` - The new state ("MASTER"|"BACKUP"|"FAULT")
  
  These scripts run in the IP failover pod and use the pod's file system, not the
  host file system. The options require the full path to the script. The
  administrator must make the script available in the pod to extract the results
  from running the *notify* script. The recommended approach for providing the
  scripts is to use a
  xref:../dev_guide/configmaps.adoc#dev-guide-configmaps[ConfigMap].
  
  The full path names of the *check* and *notify* scripts are added to the
  *keepalived* configuration file, *_ /etc/keepalived/keepalived.conf_*, which is
  loaded every time *keepalived* starts. The scripts can be added to the pod with
  a ConfigMap as follows.
  
  . Create the desired script and create a ConfigMap to hold it. The script
  has no input arguments and must return `0` for *OK* and `1` for *FAIL*.
  +
  The check script, *_mycheckscript.sh_*:
  +
  [source,bash]
  ----
  #!/bin/bash
      # Whatever tests are needed
      # E.g., send request and verify response
  exit 0
  ----
  
  . Create the ConfigMap:
  +
  ----
  $ oc create configmap mycustomcheck --from-file=mycheckscript.sh
  ----
  
  . There are two approaches to adding the script to the pod: use `oc` commands or
  edit the deployment configuration.
  
  .. Using `oc` commands:
  +
  [source,bash]
  ----
  $ oc env dc/ipf-ha-router \
      OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh
  