Applies To:
Show VersionsBIG-IQ Centralized Management
- 5.1.0
How do I evaluate changes made to managed objects?
To change the object settings on a managed device, there are four tasks to perform.
This figure illustrates the workflow you perform to manage the objects on BIG-IP® devices. Evaluating the changes you have made is the third step in this process.
Overview of evaluating changes made to managed objects
How do I deploy changes made to managed objects?
Deploying changes applies the revisions that you have made on the BIG-IQ® to the managed BIG-IP® devices.
- To accept the default, proceed with the deployment. The settings from the managing BIG-IQ overwrite the settings on the managed BIG-IP device.
- To override the default, rediscover the device and reimport the service. Any changes that have been made using the BIG-IQ are overwritten with the settings from the managed BIG-IP device.
This figure illustrates the workflow you perform to manage the objects on BIG-IP devices. Deploying the settings is the last step in this process.
Change managed object workflow
How does deployment to devices in a cluster work?
When you created a cluster in BIG-IQ® inventory, you chose a deployment option for the devices in that cluster.
If you chose to initiate BIG-IP® DSC® sync, and the Sync-Failover group on the BIG-IP system is configured for manual sync, after deployment to either device in the HA pair, Access kicks off manual sync to the other device. If manual sync succeeds, the deployment is successful. Otherwise, the deployment status shows an error.
If you chose to initiate BIG-IP DSC sync and the Sync-Failover group on the BIG-IP system is configured for automatic sync, after deploying to either device in the HA pair, automatic sync propagates the configuration to the other device. If automatic sync succeeds, the deployment is successful. Otherwise, the deployment status shows an error.
If you chose to ignore BIG-IP DSC sync, you must deploy the configuration from BIG-IQ to both devices in the cluster.
Evaluating Access configuration changes
To apply the object changes to the managed device, you must deploy them.
Evaluating LTM configuration changes
To apply the object changes to the managed device, you must deploy them.
Deploying LTM configuration changes
When a BIG-IQ® system evaluation of the Access configuration advises you to, you should deploy LTM®before you deploy Access.
- If you chose to deploy immediately, the changes begin to deploy and the Status column updates as it proceeds.
- If you choose to delay deployment, the Status column displays the scheduled date and time.
Deploying the Access configuration
- If you chose to deploy immediately, the changes begin to deploy and the Status column updates as it proceeds.
- If you choose to delay deployment, the Status column displays the scheduled date and time.
Access deployment errors and warnings: causes and resolutions
Problem | Description | Resolution |
---|---|---|
Access profile type mismatch | The deployment process imports an access profile from the source device to the other devices in the Access group. If an access profile of the same name exists on a non-source device, the access profile types must match. If it does not, a critical error occurs and deployment fails. | On the non-source BIG-IP® device, delete the access profile. Then, redeploy on the BIG-IQ® system. |
Sandbox object outside of the /Common partition | If partitions exist on the source device in addition to the /Common partition, they contain sandbox objects by default. When the deployment process tries to create the sandbox objects, if the same partitions do not exist on the non-source devices, a critical error occurs and deployment fails. | On each non-source BIG-IP device, create the same partitions that exist on the source device. Then, redeploy on the BIG-IQ system. |
Machine account | A machine account exists on the source device, but does not exist on a non-source device. A critical error occurs when the deployment process tries to create a machine account on non-source BIG-IP system. | On each non-source BIG-IP device, create a machine account of the same name as the one on the source device. Then, redeploy on the BIG-IQ system. |
Non-Access objects | The deployment evaluation process finds that certain virtual servers, SSL profiles, and other objects are used by access policies on the source device but are not present on a non-source device. A critical error occurs because the deployment process cannot create objects not managed by Access. | Create the objects on the non-source BIG-IP devices where needed. Then, redeploy on the BIG-IQ system. |
Pools, pool members, self IPs, route domains | Access objects refer to pools, pool members, self IP addresses, and route domains, all of which are managed in ADC. If any of these objects is not present on the source device, evaluation provides a warning that LTM® must be deployed before Access can be deployed. If the warning is ignored, Access deployment fails. | Deploy LTM. Then re-discover LTM before trying to deploy Access. |
Adding or updating an OAM server | An Oracle Access Manager (OAM) AAA server exists on the source device. If the deployment process must add or update the OAM server on a non-source device, a message displays advising that the eam service on the BIG-IP device must be restarted. The deployment succeeds. | After the deployment completes, restart the eam service on the non-source BIG-IP device. |