VCF Identity Broker repeatedly deploys an additional fourth VM after upgrade or patch due to VIP IP address overlap in the configured IP pool range

Products

• VCF Operations

Issue/Introduction

Following an upgrade or patch operation initiated through VCF Fleet Management for VCF Identity Broker component, the VCF Identity Broker (vIDB) environment may continuously attempt to deploy an additional fourth VM node on the vCenter Server. This behavior can cause instability within the VCF Identity Broker environment and may affect VCF SSO authentication services.

Environment

• VCF Operations 9.0.x
• VCF Fleet Management 9.0.x
• VCF Identity Broker 9.0.x

Cause

The issue occurred because the configured VIP IP address was included within the defined IP pool range used for the VCF Identity Broker deployment.

 

The following configuration can be identified in the environment. Follow the below steps to verify the same:

• SSH into any node of VCF Identity Broker appliance as vmware-system-user
• Switch to root account using sudo -i
• Run the following command to view the configuration:

  kubectl get pd -n vmsp-platform vmsp-platform -o yaml | less

• Search for the networking section and find the IP pool: (Note: Do not make changes to this file manually)

  vips:
            additional: []
            primary: #.#.#.#           <------------This IP address is included within the IP pool range.
        internal:
          cidr: #.#.#.#/##
        ipPool:
          addresses:
          - #.#.#.#-#.#.#.#            <------------IP Pool
          excludedAddresses: []
          gateway: #.#.#.#
          prefix: "#"

Resolution

To resolve the issue:

1. Redeploy the VCF Identity Broker component from the Fleet Management. Refer: Deploying VCF Identity Broker
2. While deploying, ensure the VIP IP address is excluded from the configured IP pool range.
3. Perform a backup and restore configuration/data for the VCF Identity Broker environment. Refer: Restore a VCF Identity Broker Appliance Cluster

Additional Information

• The redeployment and restore process must be performed using the same network range.
• Ensure a recent and valid backup is available before starting the redeployment procedure.
• The replacement cluster deployment must match the original deployment configuration and the version for which the backup was taken, including:
  • Node count
  • Sizing
  • Software version

In case there is a similar problem observed with VCF Automation 9.0.x, refer Changing the Cluster VIP Address in VCF Automation 9.0