anchor.diff:  The approach is to specify an `ingressIPNetworkCIDR` range and then use the same range in creating the ipfailover configuration.
   
   Since, ipfailover can support up to a maximum of 255 VIPs for the entire cluster, the `ingressIPNetworkCIDR` needs to be `/24` or less.
  -
  
positive.code: 
  The `iptables` rule can be removed after the last *keepalived* daemon terminates. The rule is not automatically removed.
  
  You can manually manage the `iptables` rule on each of the nodes. It only gets created when none is present (as long as ipfailover is not created with the -`-iptable-chain=""` option).  
  
  [IMPORTANT]
  ====
  
negative.code: The VIPs must be routable from outside the cluster.
  ====
  
  IP failover monitors a port on each VIP to determine whether the port is
  reachable on the node. If the port is not reachable, the VIP will not be
  assigned to the node. If the port is set to `0`, this check is suppressed.
  xref:check-notify[The *check* script] does the needed testing.
  
  IP failover uses link:http://www.keepalived.org/[*Keepalived*] to host a set of
  externally accessible VIP addresses on a set of hosts. Each VIP is only serviced
  by a single host at a time. *Keepalived* uses the VRRP protocol to determine
  which host (from the set of hosts) will service which VIP. If a host becomes
  unavailable or if the service that *Keepalived* is watching does not respond,
  the VIP is switched to another host from the set. Thus, a VIP is always serviced
  as long as a host is available.
  
  The administrator can provide a script via the `--notify-script=` option, which
  is called whenever the state changes. *Keepalived* is in *MASTER* state when it
  is servicing the VIP, in *BACKUP* state when another node is servicing the VIP,
  or in *FAULT*` state when the *check* script fails. The
  xref:check-notify[*notify* script] is called with the new state whenever the
  state changes.
  
  {product-title} supports creation of IP failover deployment configration, by
  running the `oadm ipfailover` command. The IP failover deployment configration
  specifies the set of VIP addresses, and the set of nodes on which to service
  them. A cluster can have multiple IP failover deployment configurations, with
  each managing its own set of unique VIP addresses. Each node in the IP failover
  configuration runs an IP failover pod, and this pod runs *Keepalived*.
  
  When using VIPs to access a pod with host networking (e.g. a router), the
  application pod should be running on all nodes that are running the ipfailover
  pods. This enables any of the ipfailover nodes to become the master and service
  the VIPs when needed. If application pods are not running on all nodes with
  ipfailover, either some ipfailover nodes will never service the VIPs or some
  application pods will never receive any traffic. Use the same selector and
  replication count, for both ipfailover and the application pods, to avoid this
  mismatch.
  
  While using VIPs to access a service, any of the nodes can be in the ipfailover
  set of nodes, since the service is reachable on all nodes (no matter where the
  application pod is running). Any of the ipfailover nodes can become master at
  any time. The service can either use external IPs and a service port or it can
  use a nodePort.
  
  When using external IPs in the service definition the VIPs are set to the
  external IPs and the ipfailover monitoring port is set to the service port.  A
  nodePort is open on every node in the cluster and the service will load balance
  traffic from whatever node currently supports the VIP. In this case, the
  ipfailover monitoring port is set to the nodePort in the service definition.
  
  [IMPORTANT]
  ====
  