Description of problem:

Customer needs to allocate a new cidr network to the machine network when the load balancer is not on the machine network. They are only allocated 2 consecutive ip's. sometimes this requires a cider address that contains other addresses that they do not own.  Customer wants to make sure that those additional addresses cannot be used by the cluster and if they are used by the cluster, how can this be remediated.

    

Version-Release number of selected component (if applicable):

4.16
    

How reproducible:

easy to set up. i am allocated 2 VIPs for api and ingress not on the machine network
192.168.1.2/192.168.1.3
smallest cidr possible is 192.168.1.0/29 which contains spare addressees 1,4,5,6

These addresses may be used by the address owner (not this customer)
Does this create a dual assignment possibility?
Will the cluster ever use those addresses

sample install-config key lines marked with <------------

additionalTrustBundlePolicy: Proxyonly
apiVersion: v1
baseDomain: bcbsnc.com
compute:

• architecture: amd64
  name: worker
  platform:
  vsphere:
  cpus: 8
  coresPerSocket: 8
  memoryMB: 32768
  osDisk:
  diskSizeGB: 120
  replicas: 3
  controlPlane:
  architecture: amd64
  name: master
  platform:
  vsphere:
  cpus: 8
  coresPerSocket: 8
  memoryMB: 32768
  osDisk:
  diskSizeGB: 120
  replicas: 3
  metadata:
  creationTimestamp: null
  name: ocpdd
  networking:
  clusterNetwork:
• cidr: 10.40.0.0/14
  hostPrefix: 22
  machineNetwork:
• cidr: 10.242.8.0/22
• cidr: 10.242.82.92/29 <------------
  networkType: OVNKubernetes
  serviceNetwork:
• 10.44.0.0/16
  platform:
  vsphere:
  hosts:
• role: bootstrap
  networkDevice:
  ipAddrs:
• 10.242.8.25/22
  gateway: 10.242.8.1
  nameservers:
• 10.240.24.10
• 10.240.30.10
• 10.100.193.10
• role: control-plane
  networkDevice:
  ipAddrs:
• 10.242.8.26/22
  gateway: 10.242.8.1
  nameservers:
• 10.240.24.10
• 10.240.30.10
• 10.100.193.10
• role: control-plane
  networkDevice:
  ipAddrs:
• 10.242.8.27/22
  gateway: 10.242.8.1
  nameservers:
• 10.240.24.10
• 10.240.30.10
• 10.100.193.10
• role: control-plane
  networkDevice:
  ipAddrs:
• 10.242.8.28/22
  gateway: 10.242.8.1
  nameservers:
• 10.240.24.10
• 10.240.30.10
• 10.100.193.10
• role: compute
  networkDevice:
  ipAddrs:
• 10.242.8.10/22
  gateway: 10.242.8.1
  nameservers:
• 10.240.24.10
• 10.240.30.10
• 10.100.193.10
• role: compute
  networkDevice:
  ipAddrs:
• 10.242.8.9/22
  gateway: 10.242.8.1
  nameservers:
• 10.240.24.10
• 10.240.30.10
• 10.100.193.10
• role: compute
  networkDevice:
  ipAddrs:
• 10.242.8.8/22
  gateway: 10.242.8.1
  nameservers:
• 10.240.24.10
• 10.240.30.10
• 10.100.193.10
  loadBalancer:
  type: UserManaged
  apiVIPs:
• 10.242.82.94 <------------
  ingressVIPs:
• 10.242.82.95 <------------
  failureDomains:
• name: dc15-failure-domain
  region: dc15-failure-region
  server: vavcenp001.bcbsnc.com
  topology:
  computeCluster: /ENTERPRISE-PROD-01/host/EQX15-OCP-001
  datacenter: ENTERPRISE-PROD-01
  datastore: /ENTERPRISE-PROD-01/datastore/OCP_NFS_Datastores/EQX15_NFS_DS_OCP_NON_PROD_001
  networks:
• 2008-OCP-NON-PROD_10.242.8.0_22
  resourcePool: /ENTERPRISE-PROD-01/host/EQX15-OCP-001/Resources
  folder: /ENTERPRISE-PROD-01/vm/OPENSHIFT/OCPDD
  zone: dc15-failure-zone
  vcenters:
• datacenters:
• ENTERPRISE-PROD-01
  password: J9YxQYTd4S
  port: 443
  server: vavcenp001.bcbsnc.com
  user: s404657@bcbsnc.com
  diskType: thin
  fips: false
  publish: External
  pullSecret:
  sshKey: |
  ssh-ed25519