F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IQ: Core Concepts
  3. Understanding Core Features of BIG-IQ Centralized Management
Manual Chapter : Understanding Core Features of BIG-IQ Centralized Management

Applies To:

Show Versions Show Versions

BIG-IQ Centralized Management

  • 8.3.0, 8.2.0, 8.1.0, 8.0.0, 7.1.0
Manual Chapter

Understanding Core Features of BIG-IQ Centralized Management

Why should I use BIG-IQ?

You can save time by using BIG-IQ Centralized Management to manage and monitor multiple BIG-IP devices and service configurations (such as Network Security and Access) from a single, central location.
With centralized management, you can:
  • Manage and monitor multiple BIG-IP devices and service configurations from BIG-IQ, rather than having to log in to each BIG-IP device (physical, virtual, or vCMP) individually.
  • Centrally manage and monitor security policies across your BIG-IP devices, such as firewall policies and web application policies, depending on what service configurations you have installed.
  • Maintain and edit shared configuration objects, such as policies, in one place, and then deploy those objects to multiple BIG-IP devices.
  • Apply role-based authorization to specific BIG-IP services, restricting roles and permissions for some users who use only a portion of the BIG-IQ system, and define broader permissions for administrative users. For example, you can permit application owners to see only their configuration objects across multiple devices, while an administrator can see all objects.
  • Find information about objects across all BIG-IP configurations using global search, restricting the scope of the search using various search options. Once an object is found, you can review additional information about that object.

What components comprise a BIG-IQ solution?

The components that comprise A BIG-IQ solution are listed below. Which components (and how many of each) you use depends on the kind of problems your business plans to solve.
BIG-IQ centralized manager
You can use the BIG-IQ to centrally manage your BIG-IP devices, performing operations such as backups, licensing, monitoring, configuration management, and application management. Because access to each area of BIG-IQ is role-based, you can limit access to users, thus maximizing work flows while minimizing errors and potential security issues.
The BIG-IQ dashboards provide the visibility you need to facilitate these management tasks. When you set up your BIG-IQ Centralized Management (CM) with a cluster of BIG-IQ Data Collection Devices (DCDs), these dashboards show you analytics and statistics data from your managed BIG-IP services. Viewing details and trends for the analytics, events, and alerts, generated by your BIG-IP traffic, provides you the information you need to manage it efficiently and effectively.
BIG-IP devices
Each BIG-IP device runs a number of licensed services designed around application availability, access control, and security solutions. These components run on top of F5 Traffic Management Operating System (TMOS). This custom operating system is an event driven operating system designed specifically to inspect network and application traffic and make real-time decisions based on the configurations you provide. The BIG-IP software runs on both hardware and virtual environments.
BIG-IQ data collection devices
The
data collection device
 (DCD) is a specially provisioned BIG-IQ system that manages and stores the alerts, events, and analytics data from your BIG-IP systems. This solution provides F5's best insight into your network. The BIG-IQ Centralized Management (CM) uses the data that the BIG-IQ DCD collects from your managed BIG-IP devices to generate a number of dashboards. These dashboards (on the Monitoring and Application tabs) provide you with visibility into the health of your devices and the applications.
Configuration tasks on the BIG-IP system determine when and how alerts or events are triggered.
The group of data collection devices that work together to store and manage your data are referred to as the
data collection cluster
. The individual BIG-IQ DCD and BIG-IQ CM devices are generally referred to as
nodes
.
Remote storage device
The remote storage device is necessary only when your deployment includes a DCD and you plan to store backups of your events, alerts, and statistical data for disaster recovery . Remote storage is also required so that you can retain this data when you upgrade your BIG-IQ software.
Quorum DCD device
If you want BIG-IQ to automatically failover to a peer BIG-IQ in a high availability (HA) configuration, you must identify a DCD to serve as a
quorum device
. Automatic failover is an option when two BIG-IQ and one DCD are in the same Layer 2 network in on-premises environments. The quorum device is used to determine which BIG-IQ in the HA configuration is active. If communication is disrupted between the active and standby BIG-IQ in the HA pair, the BIG-IQ that can communicate with the quorum device becomes active. Automatic failover provides the option to configure a floating management (mgmt) IP address that can be used by the active BIG-IQ, supported by the Qurorum DCD over a shared, layer 2 network. The quorum device is a DCD, so it can be included in a DCD cluster. But because it is a DCD, not a BIG-IQ, it cannot be not used as a standby BIG-IQ in an HA configuration.

BIG-IQ architecture

A simple view of the system architecture illustrates the relationship between the components of the system.
This graphic shows a BIG-IQ system, composed of two BIG-IQs in a high availability configuration and a cluster of data collection devices (DCD) using remote storage, managing multiple BIG-IP devices.
Simple BIG-IQ System Architecture

How do I start managing configurations for BIG-IP devices from BIG-IQ

Centrally managing a BIG-IP device's configuration from BIG-IQ is sometimes referred to as
declaring management authority
 (DMA) over a BIG-IP device, and includes the following main tasks:
  1. Establish trust and between BIG-IQ and BIG-IP and add the BIG-IP device to the list of devices managed devices. If you do not want to manage service configurations on your BIG-IP devices, you do not have to perform the rest of the tasks.
  2. Discover the BIG-IP device's service configurations, such as ASM, AFM, DNS, and so on. You must at least discover the LTM service. You usually only need to discover the service configurations when you are first beginning to manage a BIG-IP device.
  3. Import the discovered configurations from the BIG-IP device to the BIG-IQ system and resolve any conflicts between the configurations on BIG-IP and BIG-IQ. You usually only need to perform this task when you are first beginning to manage the BIG-IP device, or after an upgrade of BIG-IQ.
  4. Edit the configurations as needed from BIG-IQ.
  5. Evaluate the configurations to ensure that there will be no deployment issues.
  6. Deploy the updated configurations back to the BIG-IP devices.
    Essentially, you perform the first three tasks to initially set up centralized management of your BIG-IP devices and services. The last three tasks (edit, evaluate, and deploy) are performed regularly as you manage your BIG-IP devices and services.

Establish trust and add BIG-IP devices for management by BIG-IQ

The first task in managing a BIG-IP device from BIG-IQ is to add it to BIG-IQ. Largely, this is making sure that the BIG-IQ system can access the device at the specified IP address and ports. This is sometimes referred to as
establishing trust
 with the BIG-IP device.
After this task is complete, all of the BIG-IQ Device functionality (inventory reporting, backup and restore, script management, licensing, password management, software upgrade, and so on) is available for the discovered device. If at least one Data Collection Device (DCD) is deployed in the environment, statistics data for device, LTM, and DNS objects can also be collected and reported.
In environments that only require centralized device management, this task might be the only one you need to perform. The remaining tasks are for those environments that want to manage service configurations, such as Network Security, as well as the devices.
Adding the BIG-IP device and establishing trust with it involves several tasks:
  1. The BIG-IQ administrator adds the IP address, user name and password for an administrative user on the BIG-IP device.
  2. If the BIG-IP device is clustered, the administrator selects how to handle deployment to the clustered devices.
  3. The BIG-IP device and the BIG-IQ system exchange certificates to create a trust relationship.
  4. For earlier versions of BIG-IP devices, the administrator might need to update the REST framework on the BIG-IP device to be able to manage it.
    There are several ways you can add BIG-IP devices to BIG-IQ so you can manage them:
    • Add and configure BIG-IP VE devices in an AWS, Azure, or VMware cloud.
    • Add BIG-IP devices to BIG-IQ and import their services in two separate steps.
    • Add multiple BIG-IP devices and add their services in one step.
    • Import multiple BIG-IP devices and add their services using a CSV file.

Discovering the service configurations on BIG-IP devices

After the devices have been added to the list of managed devices, you can discover and import the service configurations for those BIG-IP devices, such as Local Traffic, Web Application Security, and so on. In general, you want to manage all the service configurations you discover. You always need to discover and import the Local Traffic service first, since the other services depend upon it.

About conflict management when importing services

When BIG-IQ manages a BIG-IP device, it stores a copy of that device's service configuration objects. BIG-IQ uses the following terms to describe object configuration settings on your BIG-IQ and BIG-IP devices:
  • Working configuration
     is the BIG-IP service configuration located on BIG-IQ. This is the configuration you manage, edit, and deploy to your managed BIG-IP devices.
  • Current configuration
    is the BIG-IP service configuration running on a BIG-IP device, which can be different than the working configuration on BIG-IQ if changes were made directly on that BIG-IP device.
When importing a BIG-IP device's services, BIG-IQ compares the objects in its working configuration to the objects in the BIG-IP device's current configuration. If BIG-IQ finds the same type of object with the same name but different parameters, it notifies you of the conflict. For example, a conflict would occur if an HTTP profile in the current configuration (imported from the BIG-IP device) contains different properties than the HTTP profile in the working configuration on BIG-IQ.
There are three types of objects that can cause conflicts when importing a BIG-IP device's services.
  • Shared - All objects shared across BIG-IP devices, such as LTM profiles and monitors, Security policies for ASM, AFM, and APM.
  • Shared version-specific - Only LTM profile and monitor objects that are specific to a BIG-IP software version.
  • Device-specific - Objects specific to a particular BIG-IP device, and are not shared among BIG-IP devices. These objects (for example virtual servers, pools or pool members) are uniquely defined on the BIG-IP device on which they reside.
When importing a BIG-IP device's services, you must resolve any conflicts found between the BIG-IP device's working configuration and the objects in the BIG-IQ working configuration using one of the following methods:
  • Stop importing the services with the conflicts. Resolve each conflict individually on the BIG-IP device's
    Services
     screen. Continue importing services after you address the conflicts.
  • For the LTM service configuration only: If you find configuration conflicts with the LTM service, you can place the device in a silo, continue to discover other BIG-IP devices and later, go back to address the LTM service's conflict(s) for that BIG-IP device. After you address the conflicts, you can re-add the BIG-IP device and discover and import the LTM service (as well as any other licensed services).
    The option to place a BIG-IP device with a conflict in a silo to address the conflict later is available only for the LTM service. For all other services, you cannot use a silo to address conflicts.
  • Use a BIG-IQ conflict resolution policy to automatically treat all configuration object conflicts the same way if a difference is found. The BIG-IQ conflict resolution policy options are:
    Use BIG-IQ
    Keep the object settings specified in the BIG-IQ working configuration. The next time you deploy a configuration to that BIG-IP device, BIG-IQ overwrites the object settings to match the settings defined on BIG-IQ.
    Use BIG-IP
    Use the object settings specified in the BIG-IP device's configuration to replace the object settings in the BIG-IQ working configuration. For shared objects, the next time you deploy a configuration to a managed device, BIG-IQ replaces the settings for that object on the target device.
    Create Version
    For LTM monitors and profiles only: You can create and store a copy of the BIG-IP device's object(s), specific to the software version on that BIG-IP device. For shared objects, the next time you deploy a configuration to a managed device, BIG-IQ replaces the settings for that object if that BIG-IP device is running that specific version. This option allows you to store multiple versions of LTM monitors or profiles knowing that BIG-IQ will deploy the appropriate stored version to your managed devices. The next time you import services that contain LTM monitors or profiles, BIG-IQ automatically resolves conflicts against the appropriate version.

BIG-IP shared objects managed by BIG-IQ

This is a list of BIG-IP shared objects that BIG-IQ manages.
Shared Object Name
Shared Object URI Path
Version Introduced
Cipher Group
/cm/adc-core/working-config/ltm/cipher/group
Prior to 6.0
Classification Ce
/cm/adc-core/working-config/ltm/classification/ce
Prior to 6.0
Internal Data Group
/cm/adc-core/working-config/ltm/data-group/internal
Prior to 6.0
Eviction Policy
/cm/adc-core/working-config/ltm/eviction-policy
Prior to 6.0
Message Routing Diameter Profile Router
/cm/adc-core/working-config/ltm/message-routing/diameter/profile/router
Prior to 6.0
Message Routing Diameter Profile Session
/cm/adc-core/working-config/ltm/message-routing/diameter/profile/session
Prior to 6.0
Message Routing SIP Profile Router
/cm/adc-core/working-config/ltm/message-routing/sip/profile/router
Prior to 6.0
Policy Strategy
/cm/adc-core/working-config/ltm/policy-strategy
6.1
Profile DNS Logging
/cm/adc-core/working-config/ltm/profile/dns-logging
Prior to 6.0
Profile OcspStaplingParams
/cm/adc-core/working-config/ltm/profile/ocsp-stapling-params
Prior to 6.0
iRule
/cm/adc-core/working-config/ltm/rule
Prior to 6.0
DNS Revolver
/cm/adc-core/working-config/net/dns-resolver
Prior to 6.0
IP Address List
/cm/adc-core/working-config/net/ip-address-lists
Prior to 6.0
Rate Class
/cm/adc-core/working-config/net/rate-shaping/class
Prior to 6.0
FEC tunnel profile
/cm/adc-core/working-config/net/tunnels/fec
Prior to 6.0
Tunnel GRE Pofile
/cm/adc-core/working-config/net/tunnels/gre
7.0
Tunnels Ipip
/cm/adc-core/working-config/net/tunnels/ipip
Prior to 6.0
SSL Cert
/cm/adc-core/working-config/sys/file/ssl-crl
Prior to 6.0
SSL CSR
/cm/adc-core/working-config/sys/file/ssl-csr
Prior to 6.0
SSL Key
/cm/adc-core/working-config/sys/file/ssl-key
Prior to 6.0
Folder
/cm/adc-core/working-config/sys/folder
Prior to 6.0
LogConfig Alertd Destination
/cm/adc-core/working-config/sys/log-config/destination/alertd
Prior to 6.0
LogConfig Arcsight Destination
/cm/adc-core/working-config/sys/log-config/destination/arcsight
Prior to 6.0
LogConfig Local DB Destination
/cm/adc-core/working-config/sys/log-config/destination/local-db
Prior to 6.0
LogConfig Local Syslog Destination
/cm/adc-core/working-config/sys/log-config/destination/local-syslog
Prior to 6.0
LogConfig Splunk Destination
/cm/adc-core/working-config/sys/log-config/destination/splunk
Prior to 6.0
LogConfig Filter
/cm/adc-core/working-config/sys/log-config/filter
Prior to 6.0
LogConfig Publisher
/cm/adc-core/working-config/sys/log-config/publisher
Prior to 6.0
ASM Data Protection
/cm/asm/working-config/data-protection
Prior to 6.0
ASM HTTP Method
/cm/asm/working-config/http-methods
Prior to 6.0
ASM Policy
/cm/asm/working-config/policies
Prior to 6.0
ASM Server Technology
/cm/asm/working-config/server-technologies
Prior to 6.0
ASM Signature
/cm/asm/working-config/signatures
Prior to 6.0
ASM Signature Set
/cm/asm/working-config/signature-sets
Prior to 6.0
ASM Threat Campaign
/cm/asm/working-config/threat-campaigns
7.0
ASM Violation
/cm/asm/working-config/violations
Prior to 6.0
HTTP Monitor
/cm/dns/working-config/monitor/http
7.0
Profile
/cm/dns/working-config/profile
Prior to 6.0
Address List
/cm/firewall/working-config/address-lists
Prior to 6.0
Notification Rule
/cm/firewall/working-config/change-notify-rules
Prior to 6.0
NAT Destination Translation
/cm/firewall/working-config/destination-translations
Prior to 6.0
NAT Policy
/cm/firewall/working-config/nat-policies
Prior to 6.0
Policy
/cm/firewall/working-config/policies
Prior to 6.0
Port List
/cm/firewall/working-config/port-lists
Prior to 6.0
Port Misuse Policy
/cm/firewall/working-config/port-misuse-policies
Prior to 6.0
Protocol Inspection Compliance
/cm/firewall/working-config/protocol-inspection/compliance-enums
7.0
Protocol Inspection Compliance
/cm/firewall/working-config/protocol-inspection/compliances
6.1
Protocol Inspection Profile
/cm/firewall/working-config/protocol-inspection/profiles
6.1
Protocol Inspection Service
/cm/firewall/working-config/protocol-inspection/services
6.1
Protocol Inspection Signature
/cm/firewall/working-config/protocol-inspection/signatures
6.1
Schedule
/cm/firewall/working-config/schedules
Prior to 6.0
Service Policy
/cm/firewall/working-config/service-policies
Prior to 6.0
Timer Policy
/cm/firewall/working-config/service-timer-policies
Prior to 6.0
NAT Source Translation
/cm/firewall/working-config/source-translations
Prior to 6.0
Anti-Fraud Profile
/cm/security-shared/working-config/anti-fraud-profiles
Prior to 6.0
Blacklist Publisher
/cm/security-shared/working-config/blacklist-publisher/categories
Prior to 6.0
Blacklist Publisher
/cm/security-shared/working-config/blacklist-publisher/categories
Prior to 6.0
Blacklist Publisher Profile
/cm/security-shared/working-config/blacklist-publisher/profiles
Prior to 6.0
Bot Defense Anomaly
/cm/security-shared/working-config/bot-defense-anomalies
Prior to 6.0
Bot Defense Anomaly Categories
/cm/security-shared/working-config/bot-defense-anomaly-categories
Prior to 6.0
Bot Defense Class
/cm/security-shared/working-config/bot-defense-classes
Prior to 6.0
Bot Defense Profile
/cm/security-shared/working-config/bot-defense-profiles
7.1
Bot Defense Signature
/cm/security-shared/working-config/dos-bot-signature
7.1
Bot Defense Template
/cm/security-shared/working-config/bot-defense-templates
7.1
Data Sync Profile
/cm/security-shared/working-config/datasync
7.1
Bot Defense Signature
/cm/security-shared/working-config/dos-bot-signature
7.1
Bot Defense Signature Category
/cm/security-shared/working-config/dos-bot-signature-category
7.1
DoS Profile
/cm/security-shared/working-config/dos-profiles
Prior to 6.0
IP Intelligence Blacklist Category
/cm/security-shared/working-config/ip-intelligence/blacklist-categories
Prior to 6.0
IP Intelligence Feedlist
/cm/security-shared/working-config/ip-intelligence/feed-lists
Prior to 6.0
IP Intelligence Policy
/cm/security-shared/working-config/ip-intelligence/policies
Prior to 6.0
Non F5 Controller
/cm/security-shared/working-config/non-f5/device
7.0
DNS Security Profile
/cm/security-shared/working-config/security-dns-profiles
Prior to 6.0
HTTP Security Profile
/cm/security-shared/working-config/security-http-profiles
Prior to 6.0
SSH Profile
/cm/security-shared/working-config/ssh-profiles
Prior to 6.0
Fraud Protection User Account
/cm/websafe/working-config/accounts
Prior to 6.0
Alert Rule
/cm/websafe/working-config/alert-rules
Prior to 6.0
Alert Type
/cm/websafe/working-config/alert-types
Prior to 6.0
Datasafe Profile
/cm/websafe/working-config/datasafe-profiles
Prior to 6.0
Feed
/cm/websafe/working-config/feeds
Prior to 6.0
Forwarding Alert Rule
/cm/websafe/working-config/forwarding-alert-rules
Prior to 6.0
Webservice Configuration
/cm/websafe/working-config/webservice-configs
Prior to 6.0

Considerations when managing BIG-IP device configurations

Keep the following facts in mind when managing BIG-IP devices from BIG-IQ.
  • It's important that you don't make configuration changes directly on a BIG-IP device your managing from BIG-IQ.
    If you do make changes locally directly on the BIG-IP device, you must re-import the BIG-IP device's configuration to resolve those changes with the BIG-IQ working configuration. If you do not re-import the configuration, a subsequent deployment of the configuration from the BIG-IQ will overwrite your local changes on the BIG-IP device.
  • Be aware of the BIG-IP device versions and features supported by your version of BIG-IQ. For example, in BIG-IQ, a feature that is supported for only BIG-IP devices running version 15.0 or later might not appear as an option to be managed for an earlier version of a BIG-IP device.
    You can find compatibility information in the
    BIG-IQ Centralized Management compatibility matrix
     on the F5 support web site, support.f5.com. In addition, review the BIG-IQ service documentation, since some features might be supported only with certain versions of BIG-IP devices.

Evaluating and reviewing configuration differences

You evaluate your working configuration changes before you attempt to deploy them to your BIG-IP devices using the screens found at
Deployment
EVALUATE & DEPLOY
. Evaluating your working configuration changes allows you to review and fix any potential problems before you deploy the configuration.
When you perform an evaluation, it compares the working configuration on the BIG-IQ system to the configuration running on the BIG-IP device, and then displays the differences for you to review. Differences can be caused by changes made to the configuration on the BIG-IQ system, or by changes made directly to the configuration on the BIG-IP device without using the BIG-IQ system. You can create an evaluation for one or for multiple BIG-IP devices.
This is a summary of what happens during the evaluation process.
  1. When you begin the evaluation process, the BIG-IQ captures the current service configuration on the BIG-IP device, creates a snapshot of the BIG-IQ working configuration, and then compares the two configurations for that device.
  2. You now can review the configuration differences using a graphical summary of the differences. You can also view the JSON code differences for each object that has been modified, added, or removed.
  3. After reviewing the differences, you take one of these actions:
    • If you are satisfied with the evaluation results, proceed with deploying the BIG-IQ working configuration to the BIG-IP device.
    • If you are not satisfied with the evaluation results, make whatever changes are needed on the BIG-IQ working configuration, and evaluate the configurations again. If you want to keep changes that were made directly on the BIG-IP device, re-import the BIG-IP device configuration, and evaluate the configuration again.
Keep the following considerations in mind when performing evaluations:
  • If there are changes to the Local Traffic service configuration, you should evaluate that working configuration first, since any changes you need to make there could affect other configurations.
  • You can use the evaluation process to review not only working configuration changes, but also changes in a configuration you captured in a snapshot.
  • You can also evaluate and deploy a selected set of objects rather than an entire configuration. This is sometimes referred to as a
    partial deployment
    .

Deploying the configurations

When you have successfully evaluated your configurations, you can then deploy them to the devices. You can schedule the deployment to occur at a later time, when your systems are not busy, and the deployment can be performed by another user with the appropriate deployment role if necessary. You might even want to have someone else review the configuration before it is deployed, to avoid issues.
When you deploy the configuration, it makes the BIG-IP configuration look exactly like what is on BIG-IQ, including overwriting changes that were made directly to the BIG-IP device or deleting items that were created directly on the BIG-IP device. The BIG-IQ configuration that is deployed is the same for all the BIG-IP devices managed. This idea of a single configuration being the same for multiple devices is sometimes referred to as the BIG-IQ configuration being the
source of truth
 for all the managed BIG-IP devices. You can perform a deployment immediately or you can schedule it to occur later.
If there are changes to the LTM service configuration, you should deploy that configuration before any other configuration, since the LTM service configuration can affect the other configurations.
If only a few changes were made to the configuration, you might be able to perform a partial deployment. Partial deployments typically complete more quickly than full deployments since only some of the configuration is being deployed. You use the screens at
Deployment
EVALUATE & DEPLOY
 to perform deployments.
BIG-IQ deploys all configuration changes to the BIG-IP device using the REST API. Once the deployment is complete, you can review the deployment job to see what changes were deployed. An object-by-object difference view in JSON format is available as well.

Other common BIG-IQ tasks and concepts

You use the essential BIG-IQ features when you add a BIG-IP device and start manage the service configurations on that BIG-IP device.
Other common features and concepts you'll use managing your configurations are:
  • Re-discovering and re-importing configurations when you encounter configuration problems.
  • Capturing and restoring snapshots of configurations so you can roll back to a previous set of changes.
  • Reviewing audit logs to see what changes have been made on the BIG-IQ system, and by whom.
  • Recognizing the difference between device-specific and shared objects, particularly when doing deployments.
  • Using device configuration templates to simplify device configuration.
  • Monitoring statistics through the dashboard.
  • Creating and managing applications.

Re-discovering and re-importing configurations when needed

Typically, once services are imported, there is no need to re-import or re-discover them. However, you might need to do so in the following cases:
  • If you added, changed, or deleted management IP addresses or virtual servers directly on the BIG-IP device.
  • If you made changes to other parts of the configuration locally on the BIG-IP device, rather than from BIG-IQ.
  • If you made upgraded the BIG-IP device's software that needs to be recognized by the BIG-IQ.
If any of these events occurred, you must re-import and re-discover the configuration to synchronize those changes with the configuration maintained on the BIG-IQ system. If you do not reconcile changes, a subsequent deployment will overwrite the changes made locally on the BIG-IP device. You re-discover and re-import a configuration using the screens found here,
Devices
BIG-IP DEVICES
.

Capturing and restoring configurations using snapshots

You can capture the working configuration on BIG-IQ using snapshots. Once created, you can compare snapshots to other snapshots or to the working configuration on BIG-IQ. You can also deploy a snapshot if needed.
If you need to roll back a change that was made to the device, you can perform an evaluation operation that compares the configuration on the BIG-IP device to a snapshot, and then deploys the snapshot to the BIG-IP device. Rolling back changes in this manner is easier and more reliable than editing the configuration to return it to a previous state. Snapshots can also be used to correct errors in the BIG-IQ working configuration, if an error is made there.
  • To evaluate and deploy a snapshot to a BIG-IP device, you use the screens at
    Deployment
    EVALUATE & DEPLOY
    .
  • To create and compare snapshots, you use the screens at
    Deployment
    SNAPSHOTS
    .
  • To restore the BIG-IQ working configuration to a snapshot configuration, you use the screens at
    Deployment
    RESTORE
    .

Reviewing BIG-IQ system changes using audit logs

To see changes on BIG-IQ, you can view its audit logs. The audit log contains information on which user account made the change, when they made the change, and other related information. Changes are shown as highlighted differences between JSON files. You use the screens at
Monitoring
AUDIT LOGS
to view audit logs for each of the services, such as Network Security or Local Traffic and Network. The Monitoring screens contain many other useful tools for understanding what is occurring on your BIG-IQ system.

How do shared objects impact my deployments?

The objects that you manage using BIG-IQ depend on associations with other, supporting objects. These supporting objects are called
shared objects
 because they are shared between multiple BIG-IP devices. When BIG-IQ evaluates a deployment to a managed device, it starts by deploying the device-specific objects. Then it examines the managed device to compile a list of the objects that are needed by other objects on that device. Then (based on the recent analysis) BIG-IQ deletes any shared objects that exist on the managed device but are not used. So, if there are objects on a managed device that are not being used, the next time you deploy changes to that device, BIG-IQ deletes the unused objects.

About configuration templates

BIG-IQ can manage multiple devices simultaneously. These devices can be located in several data centers that may be located in many different locations. To help you easily manage required configuration changes to DNS, NTP, SMTP, and Syslog for a large number of devices, you can use configuration templates.
To start, you create a configuration template, then deploy that template to certain devices. This can save a significant amount of time because you are not required to log in to each device individually to make configuration changes.

What is an application and how do I create one?

An application is just a container that houses multiple application services in the BIG-IQ user interface. There are a number of different application types you can create depending on what you plan to do with it. The work flow for creating each type varies a little.
Regardless of what kind of application you create, once all of the services are live, you can track their aggregate health and performance; or, you can drill down to track the performance of each application service.
As with every other task you can perform using BIG-IQ, creating applications requires permissions that are set up by the BIG-IQ admin. At a minimum (unless you are the Admin), your user ID must be assigned a custom Application Creator role and that role must be assigned access to the resources you need.
  • An application is a collection of application services that all work to support a common business process. By combining these into one container, you can manage all of the services required to operate that process from one place in the BIG-IQ user interface.
  • A multi-cloud, or multi-site application distributes multiple versions of a common application service across different physical locations or cloud platforms. With versions hosted on different platforms or locations, your availability improves, and the overall application health is more robust. If one data center or cloud platform goes down, application traffic just flows to the other one. Or, you might just want the performance benefits that can come from processing traffic locally.

Template Applications

The basic work flow for creating a standard application is to:
  1. Create or modify an AS3 or service catalog template that defines the objects you need in your application service.
  2. Create a new application. This creates the 'container' along with a single application service.
  3. Add additional application services needed to perform the business process you need to support.

Multi-Cloud Application

A multi-cloud application is a type of template application. It gets it's name from the location and type of application services it deploys. The basic work flow for creating a multi-cloud application is to:
  1. Create or modify an AS3 or service template that defines the objects you need in your application services.
  2. Create the application that will house your application services.
  3. Use the template to deploy an application service to one cloud provider or data center.
  4. Use the template to deploy the same application service to a second cloud provider or data center.
  5. Use a template to create a DNS application service that load balances the traffic between the two application services.
If one cloud platform or data center experiences performance issues, traffic automatically routes to the other platform, so your application continues to perform.

Legacy Application

A legacy application uses virtual servers that you have already deployed to your managed devices. Pools, pool members, nodes, and certain HTTP and TCP profiles associated with the deployed virtual servers are also included in a legacy application. With a legacy application, you can use the application dashboard to view statistics and analytic metrics without having to redeploy everything. Although you can still make changes to these objects using the Configuration tab, there are limitations on the type of edits you can make to the application itself using the application dashboard. These limits depend (in part) on the role to which your user name is assigned. For example, if you are assigned the application manager role for a specific application service, you can use the dashboard to enable, disable, or force offline virtual servers, pools, and pool members. If you need to make substantive changes to these objects, F5 recommends you redeploy the services using an AS3 template.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information