Release Notes : BIG-IQ Centralized Management 5.1.0

Applies To:

Show Versions

BIG-IQ Centralized Management

5.1.0

Original Publication Date: 12/18/2017 Updated Date: 04/18/2019

Summary:

This release note documents version 5.1.0 of BIG-IQ Centralized Management.

BIG-IQ Centralized Management 5.1.0

This release note documents version 5.1.0 of BIG-IQ Centralized Management.

About BIG-IQ

BIG-IQ Centralized Management gives you the tools you need to monitor, license, and configure BIG-IP devices, and the BIG-IQ system itself, from one location. With BIG-IQ, you can manage some or all of the following aspects of a BIG-IP system:

Access
ADC
Fraud Protection Services
Network Security
Web Application Security
Change Management
Audit Logging

Performing tasks on your managed devices from BIG-IQ saves you time because you don't have to go directly to a single BIG-IP device and log on, and make changes only to that device. Instead, you can access devices remotely, and monitor and manage several devices at once.

New features

BIG-IQ Centralized Management version 5.1.0 introduces the following new features:

System

Basic HTTP Authentication is disabled by default. See SOL43725273 for more information.

DNS

DNS sync-group support

Device

Importing of individual BIG-IP Virtual Edition Registration Keys into BIG-IQ for management and reporting
BIG-IQ Device specific audit log is now available in the web interface and can be exported to external syslog servers.
Searching, viewing, and reporting on all BIG-IP Virtual Edition licenses that have been granted by BIG-IQ in a single pane of glass.
Uploading QKview files from managed BIG-IP systems into iHealth, and retrieval of the associated report in PDF format.

Access

Support for rollback of BIG-IQ Access module work configuration
Audit Log Support
VIPRION Chassis Support

ADC

Ability to create, edit, and deploy http and https monitors
Ability to create, edit, and deploy Client SSL, Source Address Affinity Persistence, and SSL Persistence Profiles

Web Application Security

Support for ASM manual custom Signature sets

Network Security

SSH Proxy Support
Support for Port Misuse policies
Support for Port Misuse Policies and Support for iRule Sampling Rate within Rules
Integration with SevOne Performance Log Applicance

Fraud Protection Services

Enhanced username support for forwarding rules
Ability to forward HTML content to SOC
Support for incoming alerts of https

Screen resolution requirement

To properly display, the BIG-IQ system requires that your screen resolution is set to 1280x1024 or higher.

Browser support

BIG-IQ supports the following browsers and versions:

Microsoft Internet Explorer version 11 and later
Microsoft Edge version 12 and later
Mozilla Firefox version 29.x and later
Google Chrome version 34.x and later

BIG-IP compatibility

SOL14592: Compatibility between BIG-IQ and BIG-IP releases provides a summary of version compatibility for specific features between the BIG-IQ system and BIG-IP releases.

In general, this table outlines managed device compatibility:

Functional Description	Minimum BIG-IP version	Maximum BIG-IP version
Device operations	11.5.0 HF7	12.1.1 HF1
Upgrade - legacy devices	10.2.0	11.4.1
Upgrade - managed devices	11.5.0 HF7	12.1.1 HF1
ADC management	11.5.1 HF4	12.1.1 HF1
AFM	11.5.2	12.1.1 HF1
Access	12.1.0	12.1.1 HF1
ASM	11.5.3 HF1	12.1.1 HF1
FPS	11.6.0	12.1.1 HF1
DNS	12.0.0	12.1.1 HF1

User documentation for this release

For a comprehensive list of documentation that is relevant to this release, refer to the BIG-IQ 5.1.0 Documentation page.

Software installation

For instructions about how to upgrade from BIG-IQ version 4.5 or 4.6, refer to the BIG-IQ Centralized Management: Upgrading from BIG-IQ Version 4.5 or 4.6 to Version 5.1 guide.

For instructions about how to upgrade from BIG-IQ version 5.0 to 5.1 refer to the Upgrading BIG-IQ Centralized Management version 5.0 to BIG-IQ version 5.1 guide.

If your configuration uses logging nodes, please refer to the BIG-IQ Centralized Management with Logging Nodes: Upgrading from BIG-IQ Version 5.0 to Version 5.1 guide.

For procedures about specifying network options and performing initial configuration, refer to the BIG-IQ Centralized Management: Licensing and Initial Configuration guide.

Behavior changes

ID	Functional Area	Description
594000	ADC	The ability in BIG-IQ ADC to find objects related to a particular object (related-to searching) has been removed in version 5.0 and replaced with the ability to on the configuration tables, as well as across all ADC objects from the left navigation menu.
594023	ADC	In BIG-IQ version 5.0, all fine-grained RBAC features for ADC objects have been removed, with the exception of these features: pool member enable, pool member disable, pool member force-offline, and virtual server enable and disable.
594044	Device	BIG-IQ CM 5.0.0 does not support the initial licensing of BIG-IPs on hardware platforms with standalone reg keys.
615472	Platform	If you upgrade from version 5.0, and you have logging nodes configured, you must follow the upgrade procedures specific to logging nodes in the BIG-IQ Centralized Management: Upgrading from BIG-IQ Version 5.0 to BIG-IQ Version 5.1 guide. If you upgrade a system without upgrading logging nodes, this could lead to missing data.

Fixed CVE issues in 5.1.0

ID Number	CVE Number
579385	CVE-2016-0797
579406	CVE-2016-0705
580510	CVE-2016-0702
580516	CVE-2016-0799
580541	CVE-2016-2842
588359	CVE-2016-0742 CVE-2016-0746 CVE-2016-0747
594024	CVE-2016-2108,CVE-2016-2107,CVE-2016-2105,CVE-2016-2106,CVE-2016-2109
597979	CVE-2016-5021

Fixes

ID	Functional Area	Description
594536	Access	If RDP with a pool is marked shared, the pool is now created for non-source devices under ADC.
597389	Access	Pool is now added with default health monitor status None.
601563	ADC	When a Node uses a monitor with a port specified LTM Import fails with following error: Failed to copy configuration to working-config updater: Monitor XXX monitor is not allowed to attach to a node Now, LTM Import succeeds with monitor having port specification attached to node configuration.
602050	ADC	BIG-IP contains virtual-address names "any" and wildcard virtual servers with any:xxx or any6:xxx Discovery fails with error: "Error while transforming Virtual Server, Details: java.lang.IllegalArgumentException: Invalid address (any:0). Address is " BIG-IQ now properly discovers BigIPs with virtual servers that have addresses containing :any or :any6.
602296	ADC	BIG-IQ validates the MTU with a max of 9000, however there are some versions and platforms that support greater values. BIG-IQ previously failed to import values greater than 9000. Now, BIG-IQ can discover a VLAN with a larger MTU value.
612816	ADC	Import of BIG-IP config fails when when the name of a route object contains "%". Error example: Failed to copy configuration to working-config; reason: working-config updater failed: Property 'name' value 'any%2' has an invalid character that is not in the allowed set of characters '-a-zA-Z_.0-9' (white space is invalid) BIG-IQ now correctly validates and accepts the route name.
614281	ADC	If a Virtual Server uses a virtual address name for the destination rather than an IP discovery/import will fail. BIG-IQ now supports named destinations on discovery. However, BIG-IQ does not allow changing virtual server destinations to non-IPs.
614646	ADC	ADC Virtual modification fails when in partition and using route-domain. BIG-IQ now correctly validates the virtual server and route domain linkage. Discovery/import is no longer blocked.
614733	ADC	Preview of Virtual server now shows correct default pool value.
612395	App Visibility and Reporting (AVR)	If an aggregate Network or Web Application Security report fails due to unreachable device, it will now display the name of the device that was unreachable.
602933	Device	When the user unchecks LTM after clicking the "Select All" link, the link text now shows "Select All" instead of "Unselect All".
599401	Network Security (AFM)	BIG-IQ Network Security can discover and manage any configurable IP protocol on firewall rules for all supported BIG-IP versions.
608932	Network Security (AFM)	DSC sync status is correctly determined even for groups that are sub string of device names.
538639	Platform	Performance improvements for P-256 ECDH and ECDSA algorithms.
597225	Platform	Upon upgrading from 4.5, the browser could be caught in an infinite redirect loop if the preferred default page was set to "Cloud". This no longer occurs in 5.1; the user will be redirected to the System page instead of seeing an error.
597695	Platform	Web Application Security event logs will not be received on the logging node after the backup and restore process if the Web Application Security service is activated before the restore step. User should activate services only after restoring the data.
601757	Platform	We corrected a timing issue with connections between BIG-IQ and managed devices to resolve the possibility of inaccurately reporting managed BIG-IP systems as down.
609515	Platform	The list of ssl-ciphercuites used for updating the 11.5.x framework has been expanded to include newer TLS protocols.
609988	Platform	BIG-IQ has changed the way it binds to the ldap server such that it no longer requires that the user has visibility into its group membership.
488830	Web App Security (ASM)	We corrected an issue that caused the deployment of the most current policy to a device rather than the policy archived in the selected snapshot.
575209	Web App Security (ASM)	Support for manual signature sets has been added in the 5.1 release.
600145	Web App Security (ASM)	The version check run during the discovery process was changed so that it allowed the discovery of BIG-IPs running 11.5.3 HF1.
600317	Web App Security (ASM)	We corrected an issue that now allows the BIG-IQ to successfully deploy a change to an existing custom signature's attack type to some versions of TMOS 11.5.x
613205	Web App Security (ASM)	The query to get the element has changed so that the system will get policy sub-collection items in smaller batch sizes so that the timeout limits are not exceeded.

Known issues

ID	Functional Area	Description	Workaround (if available)
505455	Access	Adding a non-source device to an Access group fails when a device-specific object on the non-source device refers to an object that does not exist on the source device.	To identify and resolve the issue, you must look into logs for errors such as "Failed to re-work references" and "Unable to calculate working config id". The logs will have information on the type of object that needs to be fixed on the BIG-IP system.
507774	Access	Local User DB users cannot be managed from BIG-IQ Access. The BIG-IP APMs that use the Local DB User Management feature are not be able to use this feature from BIG-IQ Access. To manage the local users, the administrator must go to each individual BIG-IP device and make corresponding changes. BIG-IQ Access 5.0 discovers and manages a BIG-IP 12.1 with APM configured. Then the Access Object-Editor cannot be used to manage Local DB Users.	Go to each BIG-IP device that is managed from BIG-IQ to do the local db user management.
519587	Access	BIG-IQ Access device-specific objects differ on different devices in an HA configuration. BIG-IQ Access device-specific objects differ on different devices in an HA configuration. The user must modify each object on each device that is part of the cluster. Note that if a cluster name is specified when they are discovered, the device-specific objects are modified correctly. This occurs when two BIG-IP devices that are part of a sync-failover DSC cluster group are discovered in BIG-IQ, and no cluster name is specified in discovery parameters. After discovery, they are imported and an Access Group is created. When device-specific objects on one device are modified, other devices are not updated.	To work around this issue, perform one of the following workarounds: -- Specify cluster name when devices are discovered. -- Modify device-specific objects on all devices that otherwise are part of a cluster.
519685	Access	When a BIG-IP system in an HA configuration fails over to a standby device, the Source device in the Access Group does not automatically change to a standby device. The Source device in the Access Group does not automatically change to a standby device. This happens when the source device goes down and the administrator wants the system to continue working, failing over to another device as the source device.	To work around the issue. (1) log in to BIG-IQ Access. (2) Select Configuration :: Access Groups and then select an Access group by name. (3) Select a standby device or another device in the Access group and click Make Source. (4) Click Reimport Source to import the configuration from the newly designated Source device to the BIG-IQ system.
540329	Access	Deployment fails at the CHECK_DEVICE_AVAILABILITY step. Because System Setup is not complete, the deployment task fails. After upgrading the BIG-IQ system or cleaning up REST storage on it, the system displays a message stating that the user must complete System Setup. If the user ignores the message and goes ahead with device discovery, Access group creation and subsequent deployment, then the deployment request can fail at the CHECK_DEVICE_AVAILABILITY step.	To work around the issue, initiate and complete the BIG-IQ System Setup and re-attempt the deployment task.
552120	Access	Creating a BIG-IQ Access group fails when any of the following scenarios occur: First scenario: 1) Provision a BIG-IP device with Secure Web Gateway (SWG). 2) Create a per-request policy for SWG with URL filters. 3) De-provision SWG. 4) From BIG-IQ Access, discover the BIG-IP device and add it to an Access group. Second scenario: 1) On a BIG-IP system, de-provision Secure Web Gateway (SWG). 2) Import a per-request policy for SWG with URL filter from the BIG-IP system. 3) From BIG-IQ Access, discover the BIG-IP device and add it to an Access group. Creation of an Access group fails. First scenario: 1) On a BIG-IP system, provision Secure Web Gateway (SWG). 2) Create a per-request policy for SWG with URL filters. 3) Deprovision SWG. 4) In BIG-IQ Access, discover the BIG-IP device and add it to an Access group. Second scenario: 1) On a BIG-IP system, de-provision Secure Web Gateway (SWG). 2) Import a per-request policy for SWG with URL filter from the BIG-IP system. 3) In BIG-IQ Access, discover the BIG-IP device and add it to an Access group.	To identify and resolve the issue, look into logs for errors such as 'Failed to re-work references' or 'Unable to calculate working config id'. The logs will have information on what type of object needs to be fixed in BIG-IP system.
579042	Access	In rare instances, BIG-IQ Access device discovery fails with this error: Failed to transform secure field value for field <name of the field> To work around this issue, log in to the managed BIG-IP device and restart restjavad. This likely occurs when on a BIG-IP device the restjavad/ICRD is not up or cannot communicate to mcp.	bigstart restart restjavad from tmsh: restart restjavad
579557	Access	When administrator creates a Active Directory pool from BIG-IQ Access, it is created under BIG-IQ ADC as well. However, this Pool is open for all operations from ADC though it actually is created by Access. If this Pool or Pool-member is deleted from ADC by the ADC administrator, the delete is not propagated to Access and under BIG-IQ Access the Active Directory object will still show the pool/pool-member. It would confuse the user. However, this will not impact the configuration on the managed BIG-IP devices. If a Deployment is triggered from ADC and then Access, a validation error is then thrown by BIG-IP device. If BIG-IQ Access has any Active directory object in pool-mode and the pool-member is deleted from BIG-IQ ADC module, this discrepancy will be seen.	Administrator can add the deleted pool member once he sees the deployment error, and try deployment again.
586165	Access	You must deploy configuration changes for a device before you re-import services. If you don't, your changes are lost. If you add a non-source device to an Access Group, deploy LTM before you re-import.
591018	Access	BIG-IQ Access returns incorrect results if you filter on specific fields (such as Type or Access Profiles) for a device resource. Filtering results will be incorrect if user searches on such fields. If user is trying to do a search on specific fields like Type, Access Profiles, he does not get correct results, as the associations are calculated separately and are not indexed in the system.
591625	Access	A SAML IdP automation configuration specifies a local SP service, which is also known as a SAML AAA server. If you delete a SAML AAA server that is specified in a SAML IdP automation configuration on the BIG-IP system, then try to import the APM configuration into a BIG-IQ Access group, the import fails. The logs contain these exceptions: ---- [ERROR][05 May 2016 14:26:57 PDT][ConfigDifferencer] ERROR: caught java.lang.IllegalStateException: Reference comparand has no name: https://localhost/mgmt/cm/access/current-config/apm/aaa/saml/44533f70-9ded-3ab5-83d1-531a6eed62fc at com.f5.rest.workers.configmgmtbase.config.ResourceReferenceState.checkFields(ResourceReferenceState.java:104) at com.f5.rest.workers.configmgmtbase.config.ResourceReferenceState.equals(ResourceReferenceState.java:155) at com.f5.rest.workers.configmgmtbase.config.ResourceReferenceState.equals(ResourceReferenceState.java:131) at com.f5.rest.workers.configmgmtbase.config.StateUtil.equalsMember(StateUtil.java:141) at com.f5.rest.workers.access.config.state.apm.aaa.SamlIdpAutomationState.equals(SamlIdpAutomationState.java:61) at com.f5.rest.workers.access.config.state.apm.aaa.SamlIdpAutomationState.equals(SamlIdpAutomationState.java:48) ---- APM import fails.	On the BIG-IP system, edit SAML BIG-IP IdP automation configurations, and select another server from the SP Service list. On the BIG-IQ system, re-import APM configuration for the device in BIG-IQ.
601596	Access	Error message appears: "Failed submitting iControl REST transaction 1466806513336212: status:409, body:{"code":409,"message":"transaction failed:01020066:3: The requested Connectivity Resource Remote Desktop (/Common/modified_remote) already exists in partition Common.","errorStack":[],"apiError":1}" Deployment failure. Source has remote desktop configured with RDP type. Non-source has remote desktop configured with Citrix type. When deploy the working config to non-source device, the deployment fails with the following error	User can go to BIG-IP and remove desktop explicitly and re-deploy.
612292	Access	Customization file changes are not deployed when customization template and customization group objects are created in deployment. Deployment is successful. On a subsequent evaluation, it indicates that BIG-IQ customization group is different from the one on BIG-IP. Customization group files are not deployed in such cases. When customization template and corresponding customization group is deployed first time to a non-source device, deployment is successful.	Perform one more deployment and it deploys the customization group correctly.
487477	ADC	VLANs associated with a self IP must be in the default route domain with the Common partition and an ID of 0 (/Common/0). If the VLAN is a member of any other route domain in a partition, the deployment containing that self IP will fail. Cannot deploy configuration. VLANs associated with a self IP must be in the default route domain with the Common partition and an ID of 0 (/Common/0). If the VLAN is a member of any other route domain in a partition, the deployment containing this self IP will fail.	To resolve this issue, fix the configuration on the BIG-IP device, and re-discover it and its services from BIG-IQ.
560809	ADC	BIG-IP devices ship with a list of default protocol/services allowed on Self IPs configured with the "Port Lockdown" -> "Allow Default". You can modify this list through TMSH on the BIG-IQ device. If you modify this list, BIG-IQ might return evaluation differences in Change Management. Differences in evaluations for Self IPs may erroneously appear. User has modified the default list of allowed protocol/services used with the "Port Lockdown" setting. Only self ips using the "Allow default" setting will be affected.	To resolve the evaluation difference, rediscover the BIG-IP device and re-import its services.
578322	ADC	If you remove a SIP profile from a Virtual Server with a DoS profile and SIP enabled and you attempt to deploy that change, BIG-IQ ADC returns the following error: Virtual server (/Common/Cathy_VIP3_bigip2_sip): DoS profile with Protocol Security (SIP) enabled requires SIP profile." This virtual server will block deployment to the BIG-IP device until the DoS configuration is removed or the SIP profile is re-added. Virtual Server with SIP and DoS configured.	To fix this issue, re-add the SIP profile from BIG-IQ ADC. Alternatively, remove the DoS profile from BIG-IQ Network Security.
578874	ADC	A deployment scheduled at a date and time that when BIG-IQ is not operational, doesn't run when the BIG-IQ returns to full operational status. The scheduled deployment displays as waiting to occur in the Deployment section of the Configuration Management page, but BIG-IQ cannot deploy it in its current state. The scheduled deployment will not occur and the scheduled deployment cannot be rescheduled or manually deployed using the existing deployment task. Schedule a deployment for a date and time when the BIG-IQ is not operational.	To deploy the changes associated with the missed scheduled deployment, create a new deployment using the snapshot associated with that scheduled deployment, and then manually deploy the snapshot.
580103	ADC	ADC deployment fails because a DNS resolver is being used by the http-explicit profile. BIG-IQ does not know about this relationship, and BIG-IP system does not allow the DNS Resolver to be removed when referenced by the HTTP Explicit profile. Deployment will fail with a BIG-IP validation error. User wants to deploy a deletion of a DNS Resolver which is referenced by a HTTP Explicit profile.	To resolve this issue from BIG-IQ, add the device back the DNS Resolver's list of attached devices. Alternatively, on the BIG-IP device, remove the association of the HTTP Explicit profile to the DNS Resolver.
594619	ADC	If you create a referencing object in BIG-IQ ADC for Local Traffic or Network, they do not appear in the custom partition. Reference object is not displayed and cannot be selected, initially. Reference object is created in a custom partition, and user selects device before selecting partition when creating the referencing object in a custom partition.	Two workarounds exist: A) When you create the referencing object, select the partition before selecting the device that it should be deployed to. B) Alternatively, create the referencing object in the custom partition without trying to specify the reference object, and save your changes. Then, update the object to point to the referencing object.
597135	ADC	Interfaces should not be disabled for BIG-IP VCMP guests (platform z101). The BIG-IP GUI prevents interfaces from being disabled, however in some version the interface can be disabled using TMSH. This is a known issue on BIG-IP (see sol15487). Devices managed on BIG-IQ reflect the same issue where the interface for these devices can be disabled. The sol15487 indicates this will potentially interrupt traffic on the BIG-IP. BIG-IQ is managing VCMP guests and the user disables an interface.	Do not disable interfaces on VCMP guests.
610660	ADC	After successful deployment and then do an evaluation immediately, BIG-IQ UI shows a difference where there should be none. 1) The persistence profile loses its inheritance nature. mask Overriding with "none" on BIG-IQ is ignored by big-IP. BIG-IP 11.5 device treats null as "none" in this context but should not. 2) A false difference is presented to user even user does not make any change. Conditions: 1) This issue only happens on BIG-IP 11.5 device. 2) Creating A source address profile with "mask none" on BIG-IQ, assign it to a virtual server and then deploy to BIG-IP device. 3) Do an evaluation right after deployment is completed.	Always explicitly override all properties with the value user wants.
610716	ADC	When using very long (1000s of characters) passwords on LTM in BIG-IQ. Depending on the length of the passphrase provided, the passphrase will either silently fail to deploy (the rest of the Certificate Key Chain is saved correctly, but the passphrase is not) or if the passphrase is long enough, the user will receive an error like the following: Failed submitting iControl REST transaction 1471040379266663: status:400, body:{"code":400,"message":"transaction failed:01071768:3: Encryption of the field (passphrase) for object (/Common/longpass default) failed.","errorStack":[],"apiError":1} With the former case, a perpetual difference results in the diff, as BIG-IQ has the saved passphrase, but the deployment of the passphrase will never succeed. When using very long (1000s of characters) passwords on LTM in BIG-IQ. Depending on the length of the passphrase provided, the passphrase will either silently fail to deploy (the rest of the Certificate Key Chain is saved correctly, but the passphrase is not) or if the passphrase is long enough, the user will receive an error like the following: Failed submitting iControl REST transaction 1471040379266663: status:400, body:{"code":400,"message":"transaction failed:01071768:3: Encryption of the field (passphrase) for object (/Common/longpass default) failed.","errorStack":[],"apiError":1} With the former case, a perpetual difference results in the diff, as BIG-IQ has the saved passphrase, but the deployment of the passphrase will never succeed. When using very long (1000s of characters) passwords on LTM in BIG-IQ. Depending on the length of the passphrase provided, the passphrase will either silently fail to deploy (the rest of the Certificate Key Chain is saved correctly, but the passphrase is not) or if the passphrase is long enough, the user will receive an error like the following: Failed submitting iControl REST transaction 1471040379266663: status:400, body:{"code":400,"message":"transaction failed:01071768:3: Encryption of the field (passphrase) for object (/Common/longpass default) failed.","errorStack":[],"apiError":1} With the former case, a perpetual difference results in the diff, as BIG-IQ has the saved passphrase, but the deployment of the passphrase will never succeed.	Use a shorter password.
614199	ADC	Due to an issue on BIG-IP BIG-IQ cannot update the Cert Key Chain values for root profiles more than once. This operation is blocked on BIG-IQ to prevent modification from BIG-IQ which could lead to permanently blocking deployments from BIG-IQ. Cannot deploy Certificate Key Chain changes to root clientssl profile User needs to modify the Cert/Key chain values for the root Client SSL Profile.	Manage these setting on BIG-IP and re-discover and import.
614233	ADC	Browser performance is degraded On Virtual Servers, Pools, Pool Members and Nodes properties forms. Browser performance is degraded. In some browsers such as Firefox, you may see a dialog that shows "A script on this page may be busy, or it may have stopped responding". Discover a Big-IP or multiple BIG-IPs with over 1000 Profiles, Monitors or iRules that have unique fullPaths and navigate to a Virtual Server, Pool, Pool Member or Node properties page in the ADC module or open the creation form for these objects.	Use the latest version of Chrome browser for best performance.
617178	ADC	BIG-IQ cannot detect that a child source address persistence profile has inherited its parent's value. This is due to a defect on BIG-IP in versions before 11.6. On BIG-IQ the prefix value will appear to be customized on the child source address profile even though on BIG-IP it is not. This issue only applies to BIG-IP versions below 11.6. This occurs when the parent source address persistence profile (source_addr) has a mask or prefix set and a child profile has this setting as "none".	If managing versions 11.5 do not set parent source address profiles' masks. Instead manage the mask on the children directly.
617607	ADC	Instant deployments (i.e., updating the BIG-IP state of a virtual server or pool member outside of the Change Management module) within a manually-synced, clustered BIG-IP environment will result in an error being thrown for one of the two BIG-IPs. Furthermore, the two BIG-IPs will be in Changes Pending state following the deployment. The deployment will fail to one of the two devices, and the BIG-IP devices will be left in Changes Pending state. BIG-IP cluster is setup as a manually-synced cluster (Sync-Failover group is set to Manual Sync).	Log into one of the BIG-IP devices, and manually sync the changes from the one device that got the change to the other one (Click the "Changes Pending" link in the top-left corner). Or setting the cluster to automatically sync. Alternatively, the cluster can be sync'd via the BIG-IQ UI using the Device Management -> DSC Groups and syncing in the DSC Group Properties.
618007	ADC	BIG-IQ does not correctly link VLAN and interface configuration from Viprion when blade id is part of the interface name. When viewing the linkage between the interfaces and VLANSs the interfaces containing the blade id "1/1.1" will not appear to be linked to the VLANs. This occurs with interfaces including blade names.	The linkage can be re-established in the GUI of BIG-IQ. However, this made lead to deployment issues.
598406	App Visibility and Reporting (AVR)	BIG-IQ cannot create AVR reports for Network & Application and Firewall for BIG-IP devices running versions 12.0.0 or 12.0.0 HF1/HF2.	To work around this issue, upgrade to BIG-IP version 12.0.0 HF3 or later.
607928	App Visibility and Reporting (AVR)	When generating a report on a single device it may sometimes succeed and eventually start failing with "Proxy task failed" error message.	None. Under investigation.
490976	Device	Deploying a configuration template to a BIG-IP device occasionally fails and the BIG-IQ system returns a JSON configuration error. Template deployment will fail partway through the process. Earlier items will be applied, while the failing item and later items will not be. This problem can occur when the target BIG-IP device is an older version (in this case, 11.5) that does not support a particular object attribute in the configuration template.	If the error occurred because the configuration template includes a BIG-IP object attribute that does not exist in the targeted BIG-IP version, you may be able to work around the issue by editing the template through the REST API and removing the incompatible field. You cannot perform this change from the user interface. Note that the template API is not a supported API and is subject to change or removal without notice. Templates are stored in a collection at the path /mgmt/cm/autodeploy/simple-templates. To make this change, perform a GET to retrieve the current state, edit that state, then perform a PUT or PATCH to apply the updated state. You need to edit only the content field.
501508	Device	BIG-IQ file load operations (such as importing devices or uploading software images) fail when using Internet Explorer versions prior to version 10. This happens if you use Internet Explorer 9 to upload files because Internet Explorer versions prior to 10 do not contain the HTML5 file API required to upload files to a BIG-IQ system.	To work around this issue, use Microsoft Internet Explorer version 10 or later. Alternatively, use Mozilla Firefox version 29.x and later, or Google Chrome version 34.x and later.
508303	Device	vCMP guests can become unresponsive when the BIG-IQ system is creating simultaneous backups of all the vCMP guests. Guests might failover if the device targeted for failover is on the same host; the problem will become worse because the net load on the host has increased due to failover. If vCMP guests are already working at high capacity and BIG-IQ starts creating simultaneous backups on guests that share a host, it causes the overall load on the host to rise and the guests to become unresponsive.	To avoid this issue, make sure that guests within the same host are not on the same backup schedule.
508469	Device	If a managed BIG-IP device has a large clock skew (more than a few minutes) from BIG-IQ, the BIG-IQ might receive 401 authorization errors from the BIG-IP device. BIG-IQ cannot manage the BIG-IP device. BIG-IQ managing a BIG-IP device with a large clock skew.	Set the system time on the BIG-IP system to reduce the clock skew. Alternatively, configure BIG-IP system and BIG-IQ to use the same NTP server to automatically keep the system time in sync.
509028	Device	The F5 HNV Gateway Provider Plugin cannot apply updates to the remaining devices in the cluster. This occurs when a BIG-IP Device Cluster is used with the F5 HNV Gateway Provider Plugin, and one device is unavailable.
514164	Device	The BIG-IQ system does not check storage availability before it downloads a UCS backup file. This could cause the BIG-IQ system to consume all the available storage when creating a backup.	To avoid this issue, configure an alert condition for the /shared/ucs_backups file so you are notified when storage is reaching a specific threshold. The alert conditions are set from the BIG-IQ Systems group :: Properties :: Alert Conditions screen. If this issue occurs, delete any unneeded backups, and re-create the backup.
524798	Device	You have to manually reactivate a license for a replacement BIG-IQ system (RMA). This happens when you attempt automatic license reactivation for a replacement BIG-IQ system without contacting F5 Support.	To work around this issue: (1) Log into the replacement BIG-IQ system (2) Get the base-registration key for the license (3) Call F5 support (4) Ask them to set the licence's allow_move variable. (5) Re-activate the license. (6) Set the hostname (7) Restore the UCS backup.
546564	Device	The BIG-IQ system does not notify you when a backup cannot run at its scheduled time. This can occur when the BIG-IQ is not operational at the time the backup was scheduled to run, for example if the BIG-IQ is powered off.	If a scheduled backup was not created due to this issue, you must either wait for the next scheduled backup to occur, or create one explicitly. To verify that a backup was created, view the location where you store the UCS backups (typically /shared/ucs_backups/*.ucs).
559599	Device	During initial setup for the BIG-IQ 7000 platform, the license registration key is not populated. BIG-IQ cannot be licensed without a known registration key.	To work around this issue, paste the key into the field. For new hardware platforms, you can find the key in the /config directory.
568075	Device	The BIG-IQ Device data sheet incorrectly listed the height of the BIG-IQ 7000 as 4.45 inches instead of 3.45 inches.
570732	Device	If, during manual activation of a pool license, you add an extra blank line to the end of the license text, BIG-IQ returns an error when you try to grant a license from the pool.	To fix this issue, re-activate the license, making sure you add no extra lines or spaces.
575036	Device	After promoting a BIG-IQ in a high availability configuration to primary, the promoted BIG-IQ system might display warnings that some software images are missing. The popup is modal and always present when user navigates to the software installations page. This occurs when you have not uploaded a software image used in a software installation on the HA Peer or if you have deleted a software image after a software installation has completed.	To fix this issue, upload the missing software image to BIG-IQ.
575659	Device	If you add a new BIG-IP device to an existing DSC cluster and the Deployment Settings mode is different than the other devices in the cluster, BIG-IQ ignores the setting for the new device. This means the DSC Sync mode for the cluster remains set to the value initially configured for the first BIG-IP added to the DSC cluster group. This is only an issue if the value for the DSC Sync mode is different from the existing DSC cluster sync mode on a device addition to an existing DSC cluster.	To correct this issue: (1) Click the name of the newly-added BIG-IP device on the BIG-IP Device inventory screen (2) From the Properties screen, click the Edit button for the Cluster Members setting. (4) Edit the Deployment Setting to match the other cluster members.
578041	Device	In rare circumstances, device discovery fails with the following error: java.lang.IllegalStateException: Framework upgrade failed because the /usr file partition on BIG-IP (null) could not be re-mounted read-only due to the /usr file system being busy.	To workaround this issue: 1. Log in to the BIG-IP device's command line and mount /usr partition manually by typing the following commands: (1) bigstart stop restjavad (2)mount -o remount,ro /usr (3) bigstart start restjavad 2. From BIG-IQ, rediscover the BIG-IP device
578483	Device	Discovery of a new or recently upgraded BIG-IP device might fail because of communication issues between BIG-IQ and the BIG-IP device. During discovery the BIG-IQ may need to update the REST framework on the BIG-IP. The REST framework is used during BIG-IP to BIG-IQ communication. During the update process an infrequent issue may cause communication with the icrd process to fail.	To resolve this issue, from the command line of the BIG-IP device, type the following command: bigstart restart icrd
585214	Device	When using BIG-IQ to upgrade software on a managed vCMP guest, software images from the vCMP host are not used. The vCMP guest is treated the same as a non-vCMP BIG-IP. If the software image is not present on the vCMP guest, it will be copied from the BIG-IQ to the guest prior to installing. This causes upgrades of vCMP guests to be slower than they need to be, and the extra software images take up unnecessary space on the guest virtual disk.
587724	Device	After you upgrade the REST framework for a BIG-IP device running version 11.6, errors related to 404 Not Found responses might display when performing certain operations. Various operations reliant upon icrd may fail, including discovery/import of a BIG-IP device into BIG-IQ. When this occurs, there may be errors related to 404 Not Found responses to icrd endpoints (/mgmt/tm/*).	To resolve this issue, from the command line of the BIG-IP device, type the following command: bigstart restart icrd
588063	Device	Device inventory page occasionally grayed out when performing REST Framework upgrade operation. The Inventory page can appear grayed out and tasks can still be running, but the user will not receive feedback. This can occur when you start multiple REST Framework upgrade tasks from inventory page.	You can refresh the web browser to resolve the issue.
590504	Device	When a BIG-IP is removed from management in BIG-IQ, references to the BIG-IQ are not removed from the BIG-IP. BIG-IP reports that it is still managed by BIG-IP.	BIG-IQ references can be manually removed from BIG-IP so that BIG-IP no longer reports that it is managed by BIG-IQ. This is accomplished by clearing REST storage on BIG-IP. On most BIG-IP versions supported by BIG-IQ, this can be accomplished via the clear-rest-storage command.
590641	Device	The "License is expired" message might incorrectly display on BIG-IQ for a BIG-IQ device even after you re-activated the license. You can see what information the BIG-IP device is presenting to BIG-IQ by viewing the endpoint, /tm/shared/licensing/registration, on the BIG-IP device. BIG-IQ shows a "License is expired" message longer than it should. Depending on the manner of re-activation, the message could persist until the next time REST services are restarted on the device, plus up to 12 hours. If the device's license was re-activated without using the REST API (eg: if tmsh were used), the incorrect license information will persist until the next time restjavad restarts (such as via a reboot, or "bigstart restart restjavad"). Restarting restjavad will update the license information that BIG-IP device presents to BIG-IQ, but it could be up to an additional 12 hours before BIG-IQ takes notice. If the device's license was re-activated using the REST API, it can still take up to 12 hours for BIG-IQ to notice. 1. A managed device has an expired license (for example, an expired Eval period) 2. That license is re-activated, so that inspecting the device manually shows it is no longer expired.	To resolve this issue, perform one of the following steps: Reboot the BIG-IP device, then wait up to 12 hours for BIG-IQ refresh the license status. Restart REST services on the BIG-IP device by typing bigstart restart restjavad
590791	Device	The BIG-IP service re-discovery might fail with a generic error message if the BIG-IP system needs a REST framework upgrade. Service rediscovery may be failed with non specific error message. The BIG-IP device is upgraded offline. And the BIG-IP REST framework upgrade is required but not upgraded.	View the BIG-IP Device inventory list to see if the device needs a REST framework upgrade. Upgrade the REST framework if required.
593491	Device	If you re-import only one of the BIG-IP devices in a DSC cluster and make changes on it, it may cause BIG-IQ to show differences during deployment and manage them incorrectly. The device that is re-imported will show that the new changes need to be removed. The device that was not re-imported will not show the new changes at all because the status of the change in current config is set to (Not Imported). This can occur when you re-import configuration for a BIG-IP device following a sync and then create an Evaluation.	To resolve this issue, re-import all BIG-IP devices configured in a DCS cluster at the same time.
598240	Device	Because there is no ASM Logging Group in BIG-IQ version 5.0, any backup you created specifying the ASM Logging Group displays the associated BIG-IQ as "unmanaged" after you upgrade from 4.x. A version 4.x BIG-IQ backup cannot be restored to a BIG-IQ running version 5.x, so this issue is mostly cosmetic. The backup is still intact and can be used to restore the BIG-IQ if the BIG-IQ is rolled back to the prior version.
609845	Device	An iHealth upload cannot be completed for BIG-IP devices running version 12.0 (including HF1, HF2, or HF3). A fix is included in HF4. BIG-IP versions 11.x and 12.1+ are not affected.	There is no workaround within BIG-IQ. qkviews can still be taken and uploaded manually for affected BIG-IP devices.
611257	Device	BIG-IQ signals success when granting a license to am unmanaged BIG-IP hardware-based device, however, the hardware device rejects the license. The customer is led to believe the licensing operation was successful when it otherwise fails. Granting of a license from BIG-IQ to an unmanaged BIG-IP hardware device.
612044	Device	iHealth upload may fail with an the error "Request for POST on <IP address> failed: status:400". The failure message will also contain the text "Only requests [[Source: LOCAL], [Source: BIGIQ]] are supported". This occurs following a BIG-IP upgrade from an 11.5.x version.	This issue can be resolved by removing BIG-IP from BIG-IQ management and then adding it back.
613723	Device	Some QKViews may fail with an "iHealth failed to process QKView" error. The PDF iHealth report will not be available in such cases.	If this occurs, please log into your account at ihealth.f5.com for additional information on the error. Retrying the upload may resolve the issue.
614819	Device	On a BIG-IQ under high load, there can be occasional displays of the "You are not licensed yet" banner, even though the device is licensed. Performance problems can also cause managed devices to falsely appear as "unhealthy". This can be confusing to you. Certain actions may not succeed on devices that are marked "unhealthy". This is an intermittent issue under certain high-load situations.	Wait a few minutes, and the issue should resolve itself.
426774	Network Security (AFM)	The error message "HA Firewalls in device 10.1.1.1 do not match those in peer device 10.1.1.2" is issued when there is a mismatch between firewalls. This error message is not very specific about the types and names of the firewalls. Providing this information would aid the user in correcting the error.
459888	Network Security (AFM)	The BIG-IQ system is unaware of default route domain assignments in non-default BIG-IP system partitions. For example, assume you have a non-default partition with a default route domain setting of something other than zero and /partitionA has a default route domain of 5. If, from the BIG-IQ system, you assign an IP address to any firewall in /partitionA without specifying the route domain (such as 192.168.25.4), and then deploy the firewall to the BIG-IP system, the BIG-IP system assigns the default route domain (5) to the IP address. The firewall on the BIG-IQ system is still shown as 192.168.25.4, while on the BIG-IP system it is 192.168.25.4%5. The address is clear on the BIG-IP system (192.168.25.4%5), but it is less clear on the BIG-IQ system where the route domain is omitted.	You can ignore the IP address settings in the BIG-IQ system. They are benign.
473034	Network Security (AFM)	The hostname of a BIG-IP system is not valid in the search field for Network Security Deployments.	Search for a device by its IP address, and then show its related items.
474135	Network Security (AFM)	Deployment occasionally fails during distribution with the error: There is no transaction created for this user. Deployment might fail and post an error message. This failure is rare and is related to timeouts experienced for large configuration changes and devices under heavy load.	Once deployment to a specific device fails, retry the deployment operation on the same device.
478963	Network Security (AFM)	Only route-domain 0 can have VLANs from other partitions. You must assign VLANs from the same partition to all other route-domains.
488527	Network Security (AFM)	When clustering multiple BIG-IP devices together in a common cluster group, BIG-IQ Security software does not verify the BIG-IP device has been provisioned with a common set of licensed software modules. BIG-IQ clustering operation is successful when it should fail. As a result, the BIG-IP device might not perform the expected functionality, and there is no indication to the user what the problem might be. Multiple BIG-IP devices with mismatches between provisioned software modules.	When adding a BIG-IP device to a cluster group, ensure that the BIG-IP device has the same software modules provisioned as does the peer BIG-IP device.
512639	Network Security (AFM)	Firefox 42 fails when connecting to BIG-IQ version 5.0.0. Cannot use Firefox browser with BIG-IQ version 5.0.0. This is a Firefox Certificate issue. Solution is documented at Firefox website at https://support.mozilla.org/en-US/questions/1012728#answer-616338 Using Firefox 42 with BIG-IQ 5.0.0.	Rename or delete cert8.db file in Firefox config folder You can use this button to go to the currently used Firefox profile folder: 1) Help > Troubleshooting Information > Profile Directory: Show Folder 2) rename or delete file cert8.db
522260	Network Security (AFM)	DoS Profile deployment fails on BIG-IP device after changing to a different type of DoS Profile. Deployment fails on the BIG-IP device. The system posts a deployment error similar to the following: 01070734:3: Configuration error: /Common/vs-dos-profile-1: Web Security profile requires an HTTP profile to be associated with the virtual server. This occurs when using the BIG-IQ system to deploy a DoS Profile with a virtual server that has an associated Web Application Security policy (that is, an ASM security policy imported from a discovered BIG-IP device) from the BIG-IQ system, and then removing the HTTP profile from the DoS Profile configuration.	A virtual server that has been used for Web Application Security may not be used for other purposes as the profiles enabled on the virtual server currently cannot be modified on the BIG-IP device nor on the BIG-IQ system by the user explicitly. The only way to make it usable for other purposes is to remove the ASM policy and deploy it back to BIG-IP device. The HTTP profile can be removed thereafter.
540492	Network Security (AFM)	When viewed from some laptops, the screen resolution does not allow the config and refresh buttons to be seen or clicked. This causes the user to not be able to access the buttons. For example, this occurs on a laptop with a screen resolution of 1440 x 900.	Use the Web browser to zoom in to view and use the buttons.
541254	Network Security (AFM)	Changing the 'Days to keep entries' or the 'Check expiration at this time' values (under Settings) while an Audit Log archive and deletion operation is currently underway causes that operation to stop. The next operation then starts at the specified time. This can occur if you change the Audit Log Settings for the AFM or ASM Audit Logs. The impact is that Audit Log entries will stop being removed from storage and the archive to the /var/config/rest/auditArchive directory will stop. You will see an Audit Log archive/delete operation stop if you change the Audit Log Settings mid-operation.	You can wait for the next archive/delete operation to occur. Or you can specify a new time 1 day from the current time if you want the archive to happen as soon as possible. You cannot force the archive/delete operation to happen within the next 24 hours. It will occur, at the earliest, exactly 24 hours from the current time. To set the new time so that the Audit Log archive/delete will occur 1 day from the current time, select the Audit Log Settings button and enter 1 for 'Days to keep entries'. Then set the 'Check expiration at this time' to the current hour and current minute. Finally, add one additional minute before selecting the Save button.
552765	Network Security (AFM)	You might observe high CPU usage after a recent upgrade of a managed BIG-IP device. Slowness during discovery followed by temporary high CPU usage. This problem is triggered when an older REST framework is installed as part of the BIG-IP system upgrade, and is expected behavior.	If the identified BIG-IP device has been recently upgraded, make sure that correct REST framework is installed. To update the framework, use the following procedure. 1. Go to the BIG-IQ Device module, hover over the device entry. Click the gear icon and select properties. 2. Scroll to the bottom of the page, and select the 'Update Framework On Rediscover' check box. 3. Enter the credentials, and at the top of the screen, click Rediscover. 4. This pushes the newer REST framework to the BIG-IP system. For a VIPRION system, each blade is represented as a separate managed device in BIG-IQ system, and so each upgraded blade must have the current REST framework pushed to it. The high CPU issue should resolve itself after the tasks have time to complete.
553761	Network Security (AFM)	With large configurations and large numbers of BIG-IP devices under management, performance issues have become visible when performing searches in the global navigation filter. Although a solution has been developed, there is a restriction for searching in contexts. Search does not search through rules in contexts, only in policies in contexts. Therefore, search does find items in any BIG-IP device running a version that supports inline rules in all contexts. Search also does not find items in management firewall contexts that contain only inline rules for all BIG-IP versions.
556516	Network Security (AFM)	When performing a search using the Exact keyword in the Network Security Policy Editor, the search is not case sensitive.
557774	Network Security (AFM)	If you enable and modify the default values for the Bot Signatures or Bot Signature Categories settings on a version 12.0 BIG-IP device, and then attempt to discover that BIG-IP device using a BIG-IQ system, the discovery will fail because the BIG-IQ DoS Profile only supports the default values for these parameters. Additionally, if you configure a new Bot Signature category and use the category to create a bot signature list, the Action must be set to a value of None. If the Action is set to a value of Block or Report, discovery of the BIG-IP device will fail even if Bot Signatures are disabled on the BIG-IP device in the DoS profile.	Do not enable and modify the default values for the Bot Signatures or Bot Signature Categories settings on a version 12 BIG-IP device and then attempt to discover that device using a BIG-IQ system.
558494	Network Security (AFM)	When trying to discover a second chassis device as part of a BIG-IQ Security high availability (HA) configuration, you might get the error: "Unable to discover device to be managed." Managed AFM chassis devices, such as VIPRION platforms, need the device framework on each blade. While the system is updating the framework (when Update Framework is selected in the system interface), the framework is pushed to all the blades of the managed device. In the rare case in which the update fails or times out during discovery, the system shows error messages similar to the following: Discovery Failed! -- Unable to discover device to be managed - https://<device-designation>, with error You must update the device's framework before you can manage it state POST_FAILED -- Unable to discover device to be managed - https://<device-designation>, with error could not upgrade REST framework state POST_FAILED. When trying to discover a second chassis device as part of a BIG-IQ Security high availability (HA) configuration. AFM might be required to encounter this issue. This appears to be a rarely encountered, possibly environmental or timing-related issue that cannot be effectively reproduced.	To work around this, reboot the device. This clears the problem and allows the device to be discovered.
582701	Network Security (AFM)	In IE & Edge browsers, the HTML report fails to generate when the report has too much data to display, which can be caused by the user selecting a large number of devices to generate the report and/or the data per device is too large.	There are two possible workarounds: 1) Use Firefox/Chrome. 2) Try reducing the number of devices selected for the report.
583142	Network Security (AFM)	If you search for a NAT firewall policy that is attached to the Global context using the search filter above the navigation list or in the Global screen, no results will be returned. NAT firewall policies that are not attached to the Global context can be searched for and found.
583456	Network Security (AFM)	User changes to objects in LTM are not synchronized to AFM and ASM in some cases. After LTM is imported, users may change virtual server, route domain, and self IP address in LTM on the BIG-IQ system. If AFM and ASM are discovered before these changes are deployed in LTM, these changes will not be synchronized with AFM and ASM when they are imported. If AFM and ASM have been imported when these changes are made in LTM, these changes will be synchronized to AFM and ASM. If configurations in LTM, AFM, and ASM are not synchronized, AFM and ASM deployments may fail. The following conditions are required to cause this issue. 1. LTM is imported but AFM and ASM are not imported. 2. User creates, modifies and deletes virtual servers, route domains and self IP address in LTM. 3. AFM and ASM are discovered before LTM deploys the changes.	Rediscover and reimport AFM and ASM after LTM is deployed.
590102	Network Security (AFM)	Logging Profile Application Security configuration management is not supported in BIG-IQ 5.0 for devices running BIG-IP version 12.1.0. When the logProfile application subcollection is enabled: (1) After reimport of Network Security or Web Application Security services, deployment evaluation shows differences related to log profile application subcollection. (2) Deployment may then fail for this configuration for Network Security or Web Application Security services. Reimport after deployment shows spurious differences. Re-deployment of the configuration can fail. LogProfile application subcollection is enabled in the BIG-IQ system interface and applied to a virtual server on a BIG-IP device running software version 12.1.0.	This issue is fixed in BIG-IP software versions 12.1.0 HF1 and 12.1.1 and higher. Workaround is to either, not configure application security in logging profiles that are attached to virtual servers on BIG-IP devices running software version 12.1.0, or upgrade affected BIG-IP devices to software version 12.1.0 HF1 or later.
590391	Network Security (AFM)	Relationship searches performed from firewall configuration objects traverse associations only up to the firewall policy level. Relationships above the contexts (devices) are out of scope and will always return (0) as the result. This limitation is necessary to avoid excessive system resource utilization during related-to searching.	To see all relationships for a given firewall configuration, run the related-to search from the firewall policy object. The search will then traverse all relationships both up to the associated devices and down to all associated configuration objects.
593673	Network Security (AFM)	A BIG-IP cluster may go out of sync if a user tries to deploy a NAT firewall policy that is attached to a route domain. If the issue occurs, a verification warning will be shown to the user with two options: 1. Remove the NAT policy association from the route domain and create a fresh evaluation again. 2. Continue to deploy and manually apply the changes on BIG-IP devices if they are in a cluster. If the user does not follow either option, then the deployment may cause the cluster to go out of sync.	There are two workarounds: 1. Remove the NAT policy association from the route domain and create a fresh evaluation again. 2. Continue to deploy and manually apply the changes on the BIG-IP devices if they are in a cluster.
593912	Network Security (AFM)	Configuring a firewall rule with a Domain Name of the form <number>.<number>.<number> (for example, '1.2.3') is allowed by BIG-IQ but will fail on deployment to BIG-IP device. Since the BIG-IP device rejects this configuration, you should not use this form of Domain Name in the BIG-IQ. While a Domain Name of '1.2.3' is technically legal, it is not possible to use this in the configuration of firewall rules on the BIG-IP device.	None.
595302	Network Security (AFM)	Some BIG-IQ DoS Profile fields have incorrect upper boundaries for fields that support ranges. Where BIG-IP system supports up to 4294967295 for many fields, in some places BIG-IQ supports only a maximum value of 2147483647. When an incorrect upper range value is specified, the resulting error messages may not be as useful as possible. The following error messages might be displayed if you specify too large of a number for a DoS Profile field, "This value is too large" or "The system returned an unexpected error (400 Bad Request). Invalid JSON posted - could not deserialize to class com.f5.rest.workers.security.shared.config.dosProfile.state.DosProfileApplicationState."	When attempting to set the maximum value for a field, use 2147483647. Refer to the BIG-IP DoS Profile documentation to find the correct maximum value for a particular field.
595822	Network Security (AFM)	Deployments will fail if a firewall NAT policy coexists with existing LTM pools (either SNAT/LSN/Automap or LTM Pool). If a virtual server has a firewall NAT policy attached along with LTM pools (either SNAT/LSN/Automap or LTM Pool) configured, the deployment will fail. No verification warning or critical error is displayed to the user prior to the deployment failing.
596080	Network Security (AFM)	Logging profiles that are in use by a NAT policy and deployed on a BIG-IP device cannot be removed from NAT policy and deleted in one deployment step. If this happens, the system will get into a state where deployment will never succeed unless the BIG-IP configuration is reimported or the workaround is used.	To delete logging profiles, use the following steps. Step 1: Delete the logging profile reference from the NAT firewall policy. Step 2: Deploy this change to the BIG-IP device. Step 3: Remove the device association from the logging profile and then delete the logging profile. Step 4: Deploy this change to the BIG-IP device.
597094	Network Security (AFM)	In the Log Profile NAT sub-profile, if the Include Destination Address/Port check box is cleared for Start Outbound Session or End Outbound Session and deployed, the BIG-IP device does not show the value as cleared. This is caused by an issue in the BIG-IP system communication API between the BIG-IQ system and the BIG-IP device. This issue prevents the proper clearing of the value on the BIG-IP device, and will cause subsequent evaluation differences for the Log Profile. This issue only occurs if the Include Destination Address/Port was previously in the checked state on the BIG-IP device.	This issue can only be corrected by clearing the check box for the associated value on the BIG-IP device, or by upgrading to a version of BIG-IP software that has the issue resolved in the BIG-IP API.
610135	Network Security (AFM)	When a BIG-IQ 5.0 with Firewall or NAT policies containing rules using IP protocols 138 through 141 is upgraded to 5.0 HF1 or later, there are cases when a false difference is shown for those protocols after deployment. The BIG-IQ will continue to show differences between its configuration and the BIG-IP's for these protocols until the workaround is executed. Functionally the BIG-IP will behave correctly.	To correct these erroneous differences, deploy any other pending changes to the device. Following the deployment, re-import the device choosing "USE BIG-IP" in the conflict resolution screen for the rules showing a protocol difference.
617168	Network Security (AFM)	The non-Properties tab for Firewall Policies, Address Lists, Port Lists, Rule Lists, Rule Schedules, NAT Policies, Timer Policies and Port Misuse Policies will only have one item displayed if the Properties page is saved via the "Save" button and then the user immediately selects the non-Properties tab. This will make it appear like these items on the non-Properties page have been deleted. This is a display issue only.	After selecting the "Save" button on a Properties screen and immediately navigating to the adjacent tab for Firewall Policies, Address Lists, Port Lists, Rule Lists, Rule Schedules, NAT Policies, Timer Policies or Port Misuse Policies, the user should select the "Save" button again to repopulate the items for that tab. As an alternative, the user can use "Cancel" or "Save and Close" and re-edit the object. They can also use the scrollbar.
617238	Network Security (AFM)	Under both Notification Rules and Locked Objects, the filter does not find anything, including names of the rules and objects. Search cannot be used for these areas.
617266	Network Security (AFM)	If the last scheduled sevone PLA configuration push has occurred for a particular sevone PLA schedule, the end date for that schedule cannot be extended. User must create a new sevone PLA external logging device entry with a new schedule if end date is to be extended. Seen on daily, weekly, and monthly schedules.	Create a new sevone PLA external logging device entry with new schedule that contains the desired end date.
617547	Network Security (AFM)	If a timer policy rule is changed from a port based protocol to non-port-based protocol, deployment will fail with device error when the change is deployed from the BIG-IQ to the BIG-IP. Timer policy rules cannot be changed from port-based to non-port-based rules using a BIG-IQ deployment task. Seen when a BIG-IP port-based timer policy rule is changed to non-port-based rule in a BIG-IQ deployment task.	On the BIG-IQ, delete the port-based timer policy rule in the timer policy, and create a new non-port-based rule with the same name or a new name.
425406	Platform	The status of a BIG-IQ in an HA configuration always displays in the command line interface as ACTIVE.
481360	Platform	An erroneous warning icon with a 'Device is not available' error might show in either the BIG-IQ Device or BIG-IQ Security areas for managed BIG-IP devices, even though the BIG-IQ system can reach those devices. The system posts the erroneous error message that the device is not available. However, you can still reach the system using HTTPs and SSH. There is no functional issue with the BIG-IP system. The actual issue is that the BIG-IQ system fails to provide the correct status. The specific conditions under which this occurs are not easily reproducible.	None.
486335	Platform	Device discovery fails with a "Failed to establish trust" error message. Device discovery is not possible until the REST framework is downgraded on the BIG-IP. This happens when the REST Framework on the BIG-IP device is newer than the REST Framework on the BIG-IQ system.	To avoid this issue, take one of the following actions: ()From the BIG-IP system: Remove the framework RPMs and retry discovery from the BIG-IQ system, specifying to upgrade the framework on discovery. Warning: Do not perform the following procedure on BIG-IP devices running version 12.0.0. ()From the BIG-IQ system: Force the REST framework downgrade using the /lib/dco/packages/upd-adc/update_bigip.sh script with the -f argument to force the install of the framework.
496091	Platform	You might not be able to click-to-provision a BIG-IP VE machine on an ESXi host if there is a time stamp issue on the ESXi host. The BIG-IP VE will not be fully provisioned.	To determine if this is a time issue, view the BIG-IQ system /var/log/restjavad.0.log file and look for something similar to the following line: Illegal state, startTime is before oldStartTime: startTime=Wed Dec 10 22:10:27 GMT 2014; oldStartTime=Wed Dec 10 22:25:41 GMT 2014. To resolve this issue, refer to the VMWare ESXi documentation to set the NTP server or fix the NTP issue and then restart the click-to-provision VE process.
497373	Platform	When the BIG-IQ system discovers or re-discovers a multi-slot VIPRION device, it prompts the device to upgrade its framework, regardless of its current version. Framework upgrade is triggered. This happens with any framework revision present on the VIPRION device. All multi-active-slot devices are affected.	Always allow discovery to upgrade the framework, even in cases where it seems unnecessary. You can only discover devices with multiple active slots through the command line. The BIG-IQ system cannot validate the existing framework revision with this technique.
499273	Platform	When managing a large number (dozens to hundreds) of devices, you might notice the memory utilization for the BIG-IQ system is high and reports OutOfMemory exceptions in /var/log/restjavad..log or /var/tmp/restjavad.out file. If restjavad is indeed leaking socket connections, then it will eventually run out of file descriptors and/or report OutOfMemory exceptions in /var/log/restjavad..log or /var/tmp/restjavad.out. BIG-IQ restjavad is expiring outbound REST operations that haven't completed after 60 seconds. This can occur when a managed BIG-IP device is unresponsive or there are network communication problems. Shell command shows sockets that are not being closed over time: lsof -p <restjavad PID>	If you cannot communicate with the managed BIG-IP devices, attempt to fix any network communication problems by pinging or routing the BIG-IP device from the BIG-IQ system, and then restart the restjavad process on the BIG-IQ system by typing the following command: # bigstart restart restjavad
510102	Platform	Firefox version 30 or later, and Internet Explorer version 11 or later, ignore the autocomplete="off" attribute in HTML. If the password autofill behavior is not wanted, the user should disable the feature in the browser. When using one of these browsers with the default autofill or password management settings, the browser might automatically populate a password field in the BIG-IQ user interface. Firefox version 30 or later, and Internet Explorer version 11 or later ignore the autocomplete="off" attribute in HTML. If the password autofill behavior is not wanted, the user should disable the feature in the browser.	One workaround is to disable the autofill or password management features of the browser. Another workaround is to use the Google Chrome browser, which still honors autocomplete=off in HTML.
513613	Platform	If someone makes a modification to the certificate information on a managed device (for example, changing the certificate's canonical name), that device becomes unavailable to the BIG-IQ system managing it. The impact is functional, performance degradation. Any attempt to communicate with the BIG-IP device fails until restjavad is restarted on the BIG-IQ device. However, even after the restjavad restart, although BIG-IQ-to-BIG-IP device communication is restored, subsequent changes to the certificate will again disrupt communication. BIG-IQ 4.5 managing BIG-IP devices whose device certificates change.	There are two workarounds for this situation. The first (A) is the recommended workaround. Workaround A.) With this solution, communication (and device discovery) is restored and socket reuse is disabled for the BIG-IQ system. Disabling reuse can impact performance, but future changes to the authentication certificate do not disable management for the device. 1. Using SSH, log in to the BIG-IQ system as root. 2. Stop restjavad by typing the command: bigstart stop restjavad. 3. In /etc/bigstart/scripts/restjavad, edit ARGS="--port=8100 ..." to read as follows: ARGS="--port=8100 --isConnectionReUseDisabled=true ...". 4. Start restjavad by typing: bigstart start restjavad. Workaround B.) With this solution, communication (and device discovery) is restored, but future changes to the managed device's authentication certificate again disables device management and requires a restjavad restart. 1. Using SSH, log in to the BIG-IQ system as root. 2. Start restjavad by typing the command: bigstart start restjavad.
516565	Platform	BIG-IQ logs events not associated with local traffic management display in the /var/log/ltm file. BIG-IQ logs system and other events to /var/log/ltm. BIG-IQ is in use, and LTM may or may not be present in the environment.	BIG-IQ uses the /var/log/ltm file for system events and other messages based off of the TMOS architecture. If you want, you can configure BIG-IQ to save events to different local logs or set up logging to save remotely.
516649	Platform	After an upgrade to one of the interim hotfix builds, one of the BIG-IP devices might fail deployment with an auth token failure. The device needs to be removed from the ASM module and then rediscovered. deployment failure	After the upgrade to this hotfix build, remove the devices and then re-add them to clear the previous false differences that were reported.
517723	Platform	In some cases, you cannot access the BIG-IQ system user interface when you use Mozilla Firefox version 37 or later. BIG-IQ system interface becomes inaccessible or unusable with Firefox 37 or later. This can happen when you use Mozilla Firefox version 37 or later.	To work around this issue, delete the Firefox cert8.db file or open Firefox and click Help :: Troubleshooting, and go through the Refresh Firefox process. Alternatively, you can use Chrome or Internet Explorer to access the BIG-IQ system.
520171	Platform	During discovery where a Framework Upgrade is done using Root/SSH method from the BIG-IQ system interface, discovery can fail with the "Connection Refused" error message from SSH. Discovery where Framework Upgrade is done via Root/SSH method from the BIG-IQ GUI.	Sync the date and time of the source and target machines, and retry the operation.
521513	Platform	On a BIG-IQ HA setup with two devices, when you go to create a backup from the backup blade and look at the Devices box, it only shows one device in the HA-Peer group. The other device is there but cannot be seen and there are no scroll bars. This gives the impression that there are no more devices.	You can click in this box and use your arrow keys to scroll down.
521867	Platform	If the /shared disk partition is running low on disk space, a software upgrade fails with the error message: "create_ucs failed; No such file or directory". The BIG-IQ configuration is not loaded on the upgraded boot location and the software upgrade is marked as failed. The /shared partition has a limited amount of free disk space. The amount of free space required will vary based on the configuration on the BIG-IQ, but the amount required should be approximately double the size of the /var/config/rest directory.	To avoid this issue, /shared needs to have additional free space. You can accomplish this by deleting files from the /shared disk partition or by extending the disk partition to be larger (procedure described in SOL14952)
526684	Platform	When BIG-IQ updates the REST framework for a BIG-IP device, it restarts restjavad and displays the following message in the restjavad.log: [SEVERE][4][04 Jun 2015 06:32:22 UTC][RestWorkerHost][main] java.lang.NoSuchFieldError: LUCENE_47 restjavad restarts in managed device. Framework upgrade from BIG-IQ UI.	To work around this issue, from the command line of the BIG-IP device, type the following 4 commands: (1) mount -o remount,rw /usr (2) rm -rvf /usr/share/java/lucene-analyzers-common-4.2.1.jar (3) rm -rvf /usr/share/java/lucene-core-4.2.1.jar (4) mount -o remount,ro /usr
528253	Platform	When a user is logged in as a non-admin user, the Roles panel does not appear.Without the Roles panel, the non-admin user cannot determine their administrative-role assignments.
532781	Platform	The system interface reports the memory that is allocated to the BIG-IQ VE as 4096 MB, even if more memory has been allocated to the VE. To view memory allocated to a VE, a user must use the command line interface or hypervisor reporting. Greater than 4 GB of memory allocated to a BIG-IQ Virtual Edition	Use free command from the command line interface to see how much memory is allocated to the VE.
545130	Platform	This issue occurs because the SSL certificates from the system when the UCS backup was run are different (out of date) from the SSL certificates in use with the software on which the UCS restore is run. The new certificates are overwritten with the backed-up certificates, causing the HA cluster to break. HA cluster down. HA pair.	Re-establish HA cluster.
550394	Platform	When a HA sync is performed, the storage from the primary system overwrites the storage on the secondary system. This causes any active sessions to terminate on the secondary system because the auth tokens are overwritten. Minimal. Users should not be using the secondary system because any changes made on it will be overwritten on the next sync.	Log back into secondary system.
553670	Platform	After promoting the peer device to primary in a BIG-IQ HA setup, the system interface of the new primary system may come back and be accessible before all entries in the blades are populated. A finite amount of time may be needed to populate the yet-to-be-filled-in data.	A browser refresh might expedite recovery.
556553	Platform	After adding a VLAN and Self-IP address to a previously discovered BIG-IP device on VIPRION, the new VLAN and Self-IP are not read by BIG-IQ, even after rediscovery. The change in VIPRION networking configuration does not automatically update BIG-IQ.	Click the Refresh button on the device properties screen(next to the Network Config option) to sync the networking configuration.
570048	Platform	It is possible to create multiple device groups with the same display name. Since the system interface presents the display name when selecting device groups, having multiple device groups with the same name makes the selection ambiguous. User could select an incorrect device group when performing operations	Change the display name on the device group properties to disambiguate the device groups.
571812	Platform	HA cluster cannot be created. The secondary machine will have an error similar to this in the restjavad.*.log files: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@^M @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @^M @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@^M HA not functional due to inability to synchronize the datastore or UCS backups The secondary has an invalid/stale entry in known_hosts for the primary. This prevents the trust relationship from being formed and used by rsync.	From the command-line, remove the invalid entry in /root/.ssh/known_hosts
575997	Platform	Under certain conditions, a user on a workstation with multiple network interfaces may have their system interface session to the BIG-IQ terminated unexpectedly at seemingly random times. User session will be abruptly terminated, possibly resulting in the loss of whatever data was input into the current view, and the user will have to log back in. On multi homed workstations with more than one default route to the BIG-IQ, the user's workstation may be configured in such a way to allow it to switch between outbound interfaces when using the BIG-IQ web GUI. The auth token generated for the GUI session is tied to the specific IP address used to request the token. If the workstation switches interfaces during the session the BIG-IQ will refuse the auth token since it is being sent from a different address and the GUI will interpret this as a session termination. The user will be redirected to the login page. If the workstation OS is attempting to load-balance across the multiple routes, the user may end up in a loop where they log in and are immediately sent back to the login page.	If users find themselves in the situation where their OS is switching between interfaces (which should be rare) they might need to disable one of the network interfaces. For example, if using a notebook computer in a docking station with a wired ethernet and a wireless ethernet connection, the user may need to disable the wireless link while using the BIG-IQ.
581822	Platform	When IE v11 zoom is set to 100% before logging in to get to the Web Application Security snapshots screen, all snapshot columns are present. However, when IE v11 zoom is set to 125% before logging in to get to the Web Application Security snapshots screen, this issue IS seen: the snapshot name column is cut off. Once the snapshot name column is cut off, changing the zoom to any other value does NOT fix the issue: the snapshot name column continues to be cut off. Name column is cut off in display. Only seen in IE11, if initial zoom is set to 122% or greater. Issue seen at 122% zoom with screen resolution of 1920 X 1080. Issue seen IE11 version "11.0.9600.18204 Update Versions: 11.0.28 (KB3134814)", windows 7 version "6.1.7601 Service Pack 1 Build 7601".	Navigate away from Web Application Security Snapshot screen, and re-navigate back to Web Application Security Snapshot screen.
584666	Platform	Some grid columns may not be visible when the grid is too wide to fit into the current browser window. Some grid columns may not be visible when the grid is too wide to fit into the current browser window.	To work around this issue: - Increase the width of your browser window until all columns are visible. or - Change the visible columns by clicking the gear icon at the upper right corner of the grid, and adding or removing columns until the desired columns are visible.
585713	Platform	BIG-IQ Logging Snapshots cannot be restored.
585996	Platform	Both peers of a cluster are presented as Green/Active on the BIG-IQ HA Inventory screen, even though the HA cluster creation has failed, and the BIG-IQ Status indicator on top of the screen correctly displays "Red/HA Error." The HA cluster is falsely presented as Healthy and ready for failover when in reality HA failover is impossible. Something happened that prevented the initial HA Synchronization from completing or otherwise led HA cluster to become unhealthy.	To work around this issue: 1. Use the Status bar at the top of the screen to determine the definitive health status of the BIG-IQ HA cluster and its peers. 2. If the Status bar shows "HA Error", break up the unhealthy cluster by removing the secondary device on the primary device's BIG-IQ HA screen. 3. Re-add the secondary device to form a new BIG-IQ HA cluster. 4. Allow the synchronization to complete, ensure that the status indicators at the top display green/healthy status on both peers.
586391	Platform	When you deploy a BIG-IQ on a hypervisor running DHCP, the IP address you configured during the initial setup might be lost. When this happens, you can only communicate with BIG-IQ through the virtual console. Unable to communicate with the deployed BIG-IQ other than through the virtual console. VMware hypervisor running DHCP service	To fix this issue, log in to BIG-IQ from the virtual console and type the config command. This guides you through the process of reconfiguring the management address, netmask, and gateway address.
588533	Platform	The user is warned when he tries to delete the node while the service is running. He can choose to move forward to remove the service. However when he re-adds the node, activating the service might not be possible Unusable logging node after re-add Re-adding a removed node when the listener (Service is running)	To work around this issue, after the node is removed, issue a curl request to cancel the listener (ASM or Access or FPS - whichever was activated) 1. Use SSH to access the logging node 2. Get the task-ID for services by running the curl command and noting the ID field of the running task. For ASM: curl localhost:8100/cm/asm/tasks/sysloglistener/ For Access: curl localhost:8100/cm/shared/hsl/listener-tasks/ For FPS: curl localhost:8100/cm/websafe/tasks/listeners 3. Run the following curl command if the service is activated: For ASM: curl localhost:8100/cm/asm/tasks/sysloglistener/<taskid> -d ' { "Status" : "CANCEL_REQUESTED" }' For Access: curl localhost:8100/cm/shared/hsl/listener-tasks/<taskid> -d ' { "Status" : "CANCEL_REQUESTED" }' For FPS: curl localhost:8100/cm/websafe/tasks/listeners/<taskid> -d ' { "Status" : "CANCEL_REQUESTED" }'
588834	Platform	On the Logging Node Configuration screen, the Number of Logging Nodes is less. Loss of node in the cluster, if not enough nodes cluster can go to RED status and query results might be incomplete. 1. When there is a networking outage for more than 15 minutes in the cluster. 2. When user manually restarts elastic search on the Logging Node and it does not join the ES cluster.	- Log On to the BIG-IQ machine. - Remove the problematic logging node. - Re-add the logging node back to the system.
589283	Platform	If you make a change to an alert setting, it might take up to 8 hours for BIG-IQ to implement those changes.
589515	Platform	Unicode characters in the device name are translated to underscore characters when the device group is saved. Customer will not be able to use Unicode in a meaningful way in device group names.	Avoid using Unicode characters in device group names
589619	Platform	A device might be marked unavailable after an upgrade in BIG-IQ in HA case in from version 4.6 to version 5.0.0. When the version 5.0 upgrade procedure is not properly followed, upon completion of upgrade of the formerly-standby BIG-IQ, all BIG-IP devices are manageable only from the formerly-standby node. None are manageable from the formerly-active node. BIG-IQ HA upgrade	Follow the documented upgrade procedure from the version 5.0 release to avoid this issue.
590514	Platform	Certificate Expiration emails report stale Expiration Date following certificate renewal.
590962	Platform	If the guest is provisioned with more memory than the actual reservation of the memory, when at load, the BIG-IQ can become unstable and daemons could begin restarting continuously. System could become unstable.	A virtual environment BIG-IQ guest (VM) must have the memory provisioned the same as the reserved amount.
591335	Platform	The online help may not update when you switch from one context area to another. For example, if you're on a Device screen, and switch to ADC, the online help may appear as the screen you last viewed in the Device context. Sometimes it can update after a waiting period. You may have temporarily inaccurate online help. This can occur when you switch functional areas from the main BIG-IQ menu.	To work around this issue, you can close the help window and click the help icon again.
591760	Platform	User goes to System ->Logging Nodes-> "Select multiple node" -> screen and clicks Remove Node. User continues, however after a few minutes, one or more of the nodes still remains in the system interface. User sees that he was not able to delete the nodes from the logging cluster. User goes to System ->Logging Nodes-> "Select multiple node" -> Click on Remove Node. User continues, however after a few minutes, one or more of the nodes still remains in the system interface. When user goes to System -> Logging Configuration, he sees that the log node count is reduced.	To work around this issue: Remove the node again through the system interface, and it will be deleted. Sometimes, the logging service might be unavailable (check by going to system: logging->logging configuration, it will throw an error saying "Elasticsearch unavailable"), then take the following steps 1. Remove the field min_master_count in /var/config/rest/Elasticsearch/Elasticsearch.json 2. Remove the file "global*.st" in "/var/config/rest/elasticsearch/data/<cluster_name>/nodes/0/_state" 3. Run "bigstart restart Elasticsearch"
593096	Platform	To create an FPS snapshot and upgrade an FPS cluster, you must access the command line of each BIG-IQ management station. You must also use the REST API on the active BIG-IQ system. Contact F5 Support to upgrade your FPS service with a new hotfix.
593126	Platform	Firefox 46 may freeze intermittently while user is browsing the BIG-IQ system interface or attempting to access the login screen. The user might be significantly slowed by the browser's performance issues. This might occur when the user is using Firefox version 46 and using the default self-signed SSL certificate configured in webd.	Use Google Chrome to access the BIG-IQ system interface, or possibly use a version of Firefox other than v46, or use Microsoft Edge or Internet Explorer 11.
594275	Platform	Then the help display cannot be seen until the screen is refreshed. The help display is no longer visible, and cannot be brought back into the visible area. This happens when Help is dragged outside of the visible window, or when the window is resized to be small enough that the dialog box is no longer visible.	Refresh the screen to reset the position of the help display.
594289	Platform	Discovery fails due to collision of device identifiers. Inability to discover and manage BIG-IQ HA pairs, BIG-IP, and Logging Nodes. The mechanism is the same for all discovered devices in BIG-IQ. The contents of the file /config/f5-rest-device-id must be unique across all discovered devices. Cloning an image of a running BIG-IQ results in a copy of this file on both virtual appliances which violates the assumption that all devices have unique identifiers.	On the cloned device, remove the file /config/f5-rest-device-id and restart restjavad. This will generate a unique machine identifier. # bigstart stop restjavad # rm -f /config/f5-rest-device-id # bigstart start restjavad
595364	Platform	If you have configured a BIG-IQ cluster, make changes on the Primary, and want those changes to be reflected on the Secondary, then follow these instructions. Secondary BIG-IQ functionality will be interrupted while the current set of data is loaded. This can occur when the BIG-IQ HA pair has been successfully setup and is in sync.	Follow the instructions to sync up the contents of the Secondary BIG-IQ.
596082	Platform	1) The "Promote to Primary" button is functional for the secondary BIG-IQ peer when it is selected from the list, even though the cluster is in an unhealthy HA error state. 2) The "Last Successful Sync" field incorrectly displays a successful Sync completion for the first 10 minutes after the initial, unsuccessful BIG-IQ Cluster synchronization attempt. The secondary peer in the BIG-IQ HA cluster is falsely presented as up-to-date and available for failover when actually the data from the primary peer has not been synchronized, and an HA failover is impossible. Something happened that prevented the initial HA Synchronization from completing or otherwise led HA cluster to become unhealthy.	1. Use the Status bar at the top of the screen to determine the definitive health status of the BIG-IQ HA cluster and its peers. 2. If the Status bar shows "HA Error", do NOT use the "Promote to Primary" functionality of the secondary peer. 3. As soon as possible, break up the unhealthy cluster by removing the secondary device on the primary device's BIG-IQ HA screen. 4. Re-add the secondary device to form a new BIG-IQ HA cluster. 5. Allow the synchronization to complete, ensure that the status indicators at the top display green/healthy status on both peers.
597706	Platform	Discovery of a device failed and the restjavad restart with the logging message in the /var/log/daemon.log "emerg logger: Re-starting restjavad" From BIG-IQ, unable to discover the LTM module from BIG-IP device and manage it within BIG-IQ	*This workaround is only for the hood release in bug 597706-1 * As a workaround you can configure the BigIQ ADC core discovery to limit the amount of items per request. To configure the limitation, a pagination size must be set in file /var/config/rest/config/restjavad.properties.json With discovery property in the â€œadcâ€ section "discovery" : { "pageSize" : 500 } This will cause BigIQ to retrieve a maximum of 500 items per request. For collection with more than 500 items multiple request will be performed. After adding the discovery pageSize configuration the restjavad.properties.json file will look to something like this format: { "platform" : { "perfLogger" : { "infoThresholdSeconds" : "5", "fineThresholdSeconds" : "1" }, "authTokenKey" : { "algorithm" : "RS384", "bits" : 3072 }, "icrdMonitor" : { "pollingIntervalSeconds": "30", "socketExpirationSeconds": "15" } }, "asm" : { }, "afm" : { }, "adc" : { "discovery" : { "pageSize" : 500 } } } After modifying the config file restart restjavad daemon to apply the new configuration.
597850	Platform	In rare circumstances, upgrading to BIG-IQ Centralized Management 5.0.0 may fail with a Waiting for BIG-IQ services to become available error message. This issue occurs when all of the following conditions are met: You have a BIG-IQ 7000 series hardware platform. Your BIG-IQ system is running either 4.5.0 or 4.6.0. You perform a software upgrade to 5.0.0. After the installation completes, you reboot the BIG-IQ system to the same slot where you performed the upgrade, which is either running 4.5.0 or 4.6.0. You reboot the BIG-IQ system to the newly installed 5.0.0 software slot. If this occurs, The configuration of the affected BIG-IQ system is lost, which includes the discovered devices.	See SOL40338232 on support.f5.com
598318	Platform	After creating a BIG-IQ HA pair, there have been occasions where the secondary BIG-IQ's UI remains unavailable and the HA status from the primary BIG-IQ shows "Peer Down". The underlying reason is that tokumond and tokumx were stopped but never restarted. This can be seen by issuing the following command: "bigstart status" If the issue has been encountered, tokumx and tokumond will be down.	To workaround the issue, on the secondary BIG-IQ, issue the following command: bigstart restart
598407	Platform	At times when a BIG-IQ HA pairing is performed, the UI will show an "HA Error". If this issue is encountered, the secondary BIG-IQ's restjavad.0.log will show this error: "failed to synchronize cluster: java.io.IOException: Connection reset by peer"	If this issue is encountered, workaround the issue by breaking the HA pair (that is, remove the secondary device from the primary device in System Management -> Inventory -> BIG-IQ HA) and retry forming the BIG-IQ HA pair.
606787	Platform	The app-service property on BIG-IP is set to none after BIG-IQ deployment. The impacted configuration items are not part of an iApp after BIG-IQ deployment. It happens on BIG-IP 12.0.0 and later when the configuration items are managed by both BIG-IQ and iApp, and the configuration items on BIG-IQ are different from those on BIG-IP.
609403	Platform	If BIG-IQ time zone is different than browser time zone of browser accessing BIG-IQ, then the SevOne external logging device, monthly scheduled next push time, is offset as follows: monthly scheduled push time + (browser time - BIG-IQ time). This time zone difference offset behavior results in an unexpected monthly scheduled push time. Seen only for monthly push schedules.	When configuring a monthly push schedule, factor in any time zone difference between the browser time zone and the BIG-IQ time zone. For example, if browser is being run in ET (eastern time zone), and BIG-IQ is sited in a data center in CT (central time zone), offset desired monthly push time by one hour, as follows: desired push time 12:00, configured push time 11:00. NOTE: There is one hour difference between ET and CT.
612102	Platform	Elastic search restarts constantly Elastic search restarts management address change through TMSH	1. Login to BIG-IQ 2. Enter https://<BIG-IQ CM ip address>/ui/system/setup 2. Click 'Next' button, it will display "Management address" screen 3. Change the management address here (If the customer has already changed it through TMSH, just flip the "Discovery Address" radio button to "Use Management Address" option) 4. Click 'Next' button 5. Re-enter the same passwords and complete the setup
612566	Platform	After running restore operation on the Logging Cluster, the FPS alerts or ASM reports or Access Reporting is empty Alerts not visible You find the following in the restjavad logs java.lang.IllegalArgumentException: status:403, body:{"error":{"root_cause":[{"type":"index_closed_exception","reaso n":"closed","index":"websafe_2016-08-23t00-00-00-0700"}],"type":"index_closed_exception","reason":"closed","index":"websafe_2016-08-23t00-00-00-0700"}, "status":403}	Query for closed indices curl 'localhost:9200/_cat/indices?pretty Then for each closed index run the following command Worked around by issuing the command as follows:- curl -X POST 'localhost:9200/<index_name>/_open'
612852	Platform	File permissions changes needed as found by internal testing N/A
614647	Platform	A dialog can appear unexpectedly with the message "Your user session has been terminated", even though the user session is still active. The dialog is misleading because the user session is still active and valid. This can occur if there are low-level network issues between the browser and the BIG-IQ. This may occur more frequently in Internet Explorer 11 than in other browsers.	The user can reload the browser page and the dialog should go away. The user might see also encounter the issue less frequently in Chrome or Firefox than in Internet Explorer 11.
514694	System	Forms containing usernames and passwords in a Mozilla Firefox browser might not function as expected. The values for username and password display, but you cannot click the button to submit. The user might not understand why the form cannot be submitted. This would occur only in the Firefox browser, and only if the "remember passwords for sites" feature is enabled. It may also occur if the user has installed a 3rd party password management utility as an addon to Firefox.	Use one of the following solutions to work around this issue: () From the Preference setting of the Security section disable the "remember passwords for sites" feature. () Instead of using a Firefox browser, use Chrome or Internet Explorer to access the BIG-IQ system. () Retype the username and password values for all forms.
584649	System	After upgrade, the SMTP destinations are not retained. You must re-enter the SMTP destination configuration after upgrade. Occurs when you have SMTP destinations configured in a 4.x installation, and you upgrade it to 5.0.
595479	System	While attempting to upload a BIG-IQ image, sometimes the upload may get stuck and never complete. The user may have to use a web browser other than IE11, like Firefox or Chrome. This issue occurs when uploading an image using Internet Explorer 11.	Use Firefox or Chrome when attempting to upload an image.
471353	Web App Security (ASM)	When the BIG-IP sends log items to the LOG-IQ node, it does not send the encoding. Therefore, some of the content displays as question mark characters instead of the real content. For example, the request http://23.23.23.23/aXXXa (where "X" is a character with an unrecognized encoding). The only attribute that the request displays correctly is the violation_details where all the buffers are base64 encoded.
505799	Web App Security (ASM)	BIG-IQ Security Web Application Security policy in blocking mode might block legitimate traffic. Legitimate traffic that should pass the block configured for this policy might be erroneously blocked. This occurs when using pre-version 12.0.0 BIG-IP software-created BIG-IQ Security policies. Because of how the BIG-IP system communicates with the BIG-IQ system, the resulting Web Application Security policy contains no allowed URLs for the BIG-IP system.	Use BIG-IP version 12.0.0 to work around this issue.
515552	Web App Security (ASM)	When using the Web Application Security Event Log some filters are not producing the expected result set. These filters are only available on the Web Application Security Event Log GUI screens and are related to searches for events that contain a specified string.
516270	Web App Security (ASM)	On changing a virtual server's Web Application Security policy setting from one policy to another, and then deploying the change, the BIG-IQ system reported that the deployment failed. However, the policy assignment successfully changed at the BIG-IP device. This issue is dependent on fixes for 2 BIG-IP 11.5.2 HF1 issues: 464735 and 464750. This does not occur for BIG-IP devices running other software releases.
516545	Web App Security (ASM)	In the ASM policy object, the user can define custom parameters. If the user is editing an existing user defined parameter and the Data Type for the parameter is set to decimal, the deployment may fail if the Minimum or Maximum values are changed so that the number of decimal places are extended or one of the value is changed so that it appears as an integer. This is an issue with BIG-IP v11.5.2 HF1 only, and does not occur with other BIG-IP releases. The UI accepts the change, but the deployment task will fail
517069	Web App Security (ASM)	Event logs from a BIG-IP device can be configured to go through a BIG-IQ logging node to a remote BIG-IQ system, where they are aggregated from multiple BIG-IP devices onto a single BIG-IQ interface. It is possible to create a situation where some Web Application Security logs do not go through the logging node all the way to the BIG-IQ system.	Clear log storage on the BIG-IQ and the BIG-IQ logging node, remove and replace the logging profile on the BIG-IP's virtual server, and remove and replace the logging node from the BIG-IQ system's logging group.
518734	Web App Security (ASM)	The client UI appears to be functional for users who were already logged in, even though restjavad is no longer running and the underlying server is not available. It appears that the UI is hung, but the actual problem is that the server is no longer running. User logged in prior to restjavad stopping/crashing. restjavad stops/crashes. User attempts to do something in the UI with restjavad down.	Check to see if restjavad is running on the BIG-IQ, using the command: "bigstart status restjavad." Restart the restjavad process, using the command "bigstart restart restjavad." Refresh the client UI.
521595	Web App Security (ASM)	After the evaluate phase of a BIG-IQ Web Application Security deployment, if an active BIG-IP cluster device goes down before the deployment completes, the BIG-IQ system signals that the deployment has failed, but the deployment does occur on what was the standby BIG-IP device. On BIG-IQ the deployment reports a failure, but the deployment completes successfully on the remaining BIG-IP device which is now the active device.
522986	Web App Security (ASM)	When deploying the same deployment again to a BIG-IP version 11.6.0 HF4 cluster with manual sync enabled, differences are displayed that actually do not exist.	These false differences are not displayed with other versions of BIG-IP devices.
524603	Web App Security (ASM)	When comparing snapshots with differences, there is a lag where the system indicates "No differences were found." After several seconds, the incorrect message is replaced by a view of the snapshot differences.
525277	Web App Security (ASM)	Snapshots taken prior to version 4.5.0 HF2 cannot be used in 4.5.0 HF2 and later. Custom signature set support and blocking mask support has been added to the ASM component. To extend support for these new objects, references paths in the ASM policy object were changed. After an upgrade, older snapshots will have obsolete references. Running a difference report against older snapshots and attempting to restore from these snapshots will fail and report the error in the UI. Upgrading of snapshots is not supported in version 4.5.0 HF2.
525968	Web App Security (ASM)	Configuration snapshots taken before Release 4.5.0 HF2 do not contain enough information to support the BIG-IQ Web Application Security features in v4.5.0 HF2 and beyond. The BIG-IQ system cannot successfully restore them.	As a best mitigation, take configuration snapshots immediately after installing Hot Fix 2 for version 4.5.0 or any later release.
526869	Web App Security (ASM)	If a device discovery failed and was not completed successfully prior to upgrading, a device discovery error message might appear in the UI after the BIG-IP device has been upgraded. Prior to version 4.5.0 HF2, the failed discovery task was not being removed from the system. After an upgrade, the system recognizes that the obsolete task has failed and should be removed. The user is prompted the remove the task.	Click the OK button on the discovery error message. The system then removes the task and the dialog box does not reappear.
526964	Web App Security (ASM)	Discovery By BIG-IQ ASM fails with the error message: "Error received during device discovery due to missing/empty parameter name". This only happens when the BIG-IP device license expires.	Make sure the BIG-IP device is licensed and operational prior to discovery.
527759	Web App Security (ASM)	When you push a new ASM signatures file to a BIG-IP device that already has that version of the signatures file, the BIG-IP device correctly rejects the update. The BIG-IQ log message in /var/log/restjavad.n.log, however, is misleading about the cause of the push failure: The uploaded Attack signature update file does not match the current version of BIG-IP software. The problem is that the update would not change the current file, not a version mismatch.	You can ignore this error. It is benign.
531985	Web App Security (ASM)	Discovery of an ASM policy with custom signature set from a BIG-IP 11.6.0 cluster, that is deployed and redeployed to a BIG-IP 11.5.3 device cluster, creates spurious differences. This only occurs if you use the Policy Creation wizard on the version 11.6 BIG-IP device to create the custom signature set. When discovered by the BIG-IQ system and deployed and re-deployed to a version 11.5.3 BIG-IP device cluster, it creates a duplicate signature set. The custom signature set collides with its originally-deployed copy, and is renamed with an "_1" suffix. For example, if the signature set is named "Systems: Apache", the final policy on the version 11.5.3 device has a set named "Systems: Apache_1." Both copies of the signature set, "Systems: Apache" and "Systems: Apache_1," appear on the device. This is due to a BIG-IP device issue, 532030. User-defined signature sets, created manually on the BIG-IP device, do not exhibit this behavior.
533938	Web App Security (ASM)	If the user creates a custom header on the BIG-IP device with a name that contains capital letters, BIG-IQ cannot remove that custom HTTP header during a deployment, and the deployment will fail with an error like the following: AsmDistributeTaskWorker][failed] DELETE to iControl REST failed: "code":404,"message":"Could not get the Header, No matching record was found." The deployment task fails and reports an error like the following: AsmDistributeTaskWorker][failed] DELETE to iControl REST failed: "code":404,"message":"Could not get the Header, No matching record was found."	On the BIG-IP device, manually remove any custom headers containing capital letters, or change the names of the custom headers to contain only lowercase letters.
538947	Web App Security (ASM)	Unexpected user-defined signature set is created on the BIG-IP device after a user deploys custom signature sets from BIG-IQ. Unexpected user-defined signature set is created. BIG-IP issue (532030) was found when using TMOS versions 11.5.3 or 11.6.0 on the BIG-IP devices after deploying a custom signature sets from BIG-IQ.	This issue was found while when using specific versions of TMOS. The issue can be avoided by moving to TMOS v11.5.3 HF2, v11.6.0 HF6 or above.
539176	Web App Security (ASM)	In version 4.6.0, when a policy is removed from a virtual server, it is no longer automatically assigned to the special inactive VIP placeholder as in previous versions.
542812	Web App Security (ASM)	When discovering BIG-IP devices with different versions (11.6, 12.0), there is a conflict even if the policies on the BIG-IP systems are imported using the same policy file.	None.
543060	Web App Security (ASM)	Deployment from Web Application Security fails with an error similar to Malformed XML: DBD::mysql::db do failed: Duplicate entry '9-300000001' for key 'PRIMARY.' This is caused by an issue in how different signature sets can be assigned to the same filter to a policy.	Avoid assigning different signature sets with the same filter to a policy.
544039	Web App Security (ASM)	Opening the exported event logs csv file in Microsoft Excel and possibly other programs shows wrong support_id.	1. Open a new empty sheet in Excel. 2. Go to the 'data' tab and select 'from text'. 3. Select your CSV file. 4. Choose: Delimited (you can also specify character encoding). 5. Check 'command' and uncheck 'tab'. 6. Find the field (support_id), select it, and choose 'text'.
547996	Web App Security (ASM)	A policy exported from BIG-IQ in version 12.0.0 compatibility mode cannot be imported to BIG-IP version 12.0.0. Policy cannot be imported to BIG-IP version 12.0.0. This occurs when using pre-version 12.0.0 BIG-IP software-created BIG-IQ policies. Because of how the BIG-IP system communicates with the BIG-IQ system, the resulting policy cannot be imported to 12.0.0 BIG-IP.	None.
552573	Web App Security (ASM)	When deploying configuration to a BIG-IP group, the group is marked as not synced in the BIG-IP system even though the user chose "run manual sync". The group is marked as not synced on the BIG-IP system. This occurs in a group that is not configured for 'full sync'.	When configuring the HA group, select 'full sync'.
554408	Web App Security (ASM)	The Audit Log contains a section for the status of the updateAndPushSignatures task in the 'Signature file' section when you select Details. The BIG-IP device IP address does not appear in this section of the log. There is an issue that occurs if a newer version of the signature file has not been pushed to the device.	None needed. This is a cosmetic issue and does not impact functionality.
555187	Web App Security (ASM)	BIG-IQ ASM Device: the indicator that the device has been modified is not cleared. The flag is not cleared. In certain cases, users can modify the device configuration, causing the change flag to be set (which indicates that the device has been modified). Then, before deploying, the user backs out the change.	Create a deployment task which evaluates the differences between the BIG-IQ configuration and the BIG-IP configuration. In this scenario, there are no changes to deploy, so no differences appear. As determined by the deployment task, there are no changes to deploy. The pending changes indicator will be cleared.
558510	Web App Security (ASM)	Evaluation shows unexpected differences after a deployment for wildcard parameters. This is due to BIG-IP issue 559055. The issue occurs only when managing devices that are affected by that bug.
560197	Web App Security (ASM)	While discovering the device into the BIG-IQ Web Application Security module, the discovery fails with the following error message displayed in the UI: primary key was not set and cannot be generated The specified device will not be able to be discovered until the workaround is applied to the BIG-IP device. The November 2015 update to the ASM signature file add a new system type into the configuration. This configuration did not contain the required unique identifier. During the BIG-IQ discovery process, the lack of the identifier caused the discovery process to fail. The workaround provided below adds a unique identifier to the new system type.	Run the following command on the BIG-IP that you are trying to discover and then rediscover the device. perl -MF5::Utils::Rest -MF5::DbUtils -MF5::ASMConfig::Entity::SignatureSystem -e "F5::Utils::Rest::populate_uuids(dbh => F5::DbUtils::get_dbh(), rest_entities => ['F5::ASMConfig::Entity::SignatureSystem'])"
566543	Web App Security (ASM)	Discovery failure due to corrupt login page configuration on BIG-IP device. The error shown includes: Error querying iControl Rest for ASM Policy - Login enforcement. The issue happens when the BIG-IP configuration is corrupt (bug 566758). The corruption is usually caused when deploying a policy from BIG-IQ v4.6 and earlier.	On the BIG-IP device, connect to the console and run the following command: mysql -p`perl -MF5::Cfg -e 'print F5::Cfg::get_mysql_password(user => q{root})'` PLC -e 'insert into PL_POLICY_PREREQUISITE_ATTRIBUTES (policy_id) select id from PL_POLICIES p LEFT JOIN PL_POLICY_PREREQUISITE_ATTRIBUTES prereq ON p.id = prereq.policy_id where prereq.policy_id IS NULL' Attempt re-discovery.
573202	Web App Security (ASM)	Related to search for custom signature sets shows 0 signatures instead of showing the actual related signatures.	Review the signatures that are related to the set using the signatures tab in the Signature Set properties.
577670	Web App Security (ASM)	Event log records that have violations found on staged entities are not found when searching for those violations. The violations are shown as part of the details of the event log record. This happens due to BIG-IP device behavior that treats those violations differently compared to violations found in regular context (non-staged).
579422	Web App Security (ASM)	Evaluation shows unexpected differences after deployment for policy building settings (enabled). This is due to BIG-IP device behavior that alters the configuration when the configuration is synchronized. Policy building mode on the BIG-IP device is not configured as set in the BIG-IQ configuration. Happens when deploying the device groups (clusters).
582067	Web App Security (ASM)	Discovery error - "policy not found" error happens when discovering BIG-IP devices with corrupt configuration. This happens due to BIG-IP bug 451089. A corruption occurred in policy configuration, either when using binary policy import export or when policy backups are created as part of the merge procedure.	On the BIG-IP device, export the bad policy, delete it and import it back. Attempt discovery again.
584629	Web App Security (ASM)	BIG-IQ deployment task to version 11.5 BIG-IP device fails. All deployment tasks will fail. The BIG-IP device has the latest signature update file installed, and BIG-IP bug 560748 has not been fixed.	On the BIG-IP devices that are affected by the issue, connect to the console or open an SSH session and run the following command: perl -MF5::Utils::Rest -MF5::DbUtils -MF5::ASMConfig::Entity::SignatureSystem -e "F5::Utils::Rest::populate_uuids(dbh => F5::DbUtils::get_dbh(), rest_entities => ['F5::ASMConfig::Entity::SignatureSystem'])"
584797	Web App Security (ASM)	Discovery fails showing errors: "Error querying iControl Rest for ASM Policy - Url" and "Invalid value '7' for field 'type'". Discovery fails. For the issue to occur, the BIG-IP device should be configured with GWT profiles/URLs with installed version of version 11.5.x and without a fix to bug 585045.	Install a fix to bug 585045 on the BIG-IP device if such exists.
584843	Web App Security (ASM)	Unexpected differences are seen in the BIG-IQ device deployment UI for the session tracking policy attributes after a deployment to a BIG-IP device running version 12.1.0, resulting from wrong configuration set on the BIG-IP device. Unexpected differences and wrong configuration deployment. This happens for BIG-IP devices of version 12.1 that do not have a fix for bug 585054 deploying policies with customized settings for Session Tracking Violations.	Create an additional evaluation and deploy the changes.
584884	Web App Security (ASM)	There is a deployment issue of URL header based content profiles. When more than one of these profiles is deployed for a URL, some of the profiles are not deployed. This is due to BIG-IP bug 449231.	Patch the BIG-IP device with a fix to bug 449231, if one is available.
585136	Web App Security (ASM)	Deployment task fails, the error message indicates: "Failed pushing changed objects to device <device name>: Could not get the Brute Force Protection, No matching record was found.". Deploy task will fail. Happens when BIG-IQ manages BIG-IP devices with 12.x version and customized Brute Force Attack Prevention configuration, and the BIG-IP software does not contain a fix for bug 585352.	Patch the BIG-IP system with the fix to bug 585352 if available.
587060	Web App Security (ASM)	New policies deployed to BIG-IP devices might have the wrong settings for user-defined signatures if those are created on different BIG-IP devices. Wrong policy settings will be set on the target BIG-IP devices. Subsequent evaluations will show differences. This happens when user-defined signatures are created independently on different BIG-IP devices.	Evaluate and deploy again to correct the wrong settings. We also recommend that you add all user-defined signatures through BIG-IQ to avoid the issue.
590213	Web App Security (ASM)	Policy configuration is not deployed correctly to standby BIG-IP devices. Creation of evaluation after successful deployment to a device group shows differences to be deployed to the standby device as it was in time of deployment. Those differences are consistent with the BIG-IP device configuration as shown by the BIG-IP user interface. The configuration is not deployed correctly. Additional evaluations would show unexpected differences. This happens when deployment is done to a group (cluster) of BIG-IP devices that are affected by bug 578334. Only happens when a policy that did not exist on the BIG-IP device is deployed.	Install a fix to bug 578334 on the BIG-IP devices when available, or redeploy changes when the original change included the addition of a policy to BIG-IP device.
590604	Web App Security (ASM)	BIG-IQ does not manage the learn flag on BIG-IP policy sub violations - HTTP Protocol Compliance and Evasions. The configuration is not discovered/imported/deployed. Deployment of policy configurations to BIG-IP devices will result in different behavior compared to that on the BIG-IP in which the policies originated from. Note that there are not policy enforcement settings (automatic learning). The issue is only relevant to management of BIG-IP devices of versions 12 and above.
591982	Web App Security (ASM)	Policy specific signature settings (enabled, in staging) might not be deployed correctly when the deployment task deploys other relevant changes. If the deployment included any change that alters the signatures relevant for a policy, the signatures that are affected by this change are configured with the settings last set by BIG-IP system for those signatures, and not the settings that are saved in BIG-IQ. Per policy signature settings are deployed wrongly, and additional deployment task might be required to set the correct values. This happens when policy signature settings are customized on BIG-IP/BIG-IQ and the change to deploy those customizations also includes changes that make these customized signatures relevant for policies. Such changes could include signature set filter changes, adding a signature set to a policy, or change in user defined signature attributes.	Evaluate and deploy again when such changes are done
593362	Web App Security (ASM)	BIG-IQ does not manage the follow schema link flag on BIG-IP policy xml profiles. The configuration is not discovered/imported/deployed. The flag has a default of enabled, which will be set on the devices managed by BIG-IQ.
593678	Web App Security (ASM)	Critical error shown on deployment for 12.x devices with policies originated from 11.x devices. The error states that policy builder settings and violation settings are inconsistent. Example: "Policy /Common/aaa: can't be used on a BIG-IP version 12.0.0. checkMaximumCookieHeaderLength value (true) on policy builder and the matching violation: VIOL_COOKIE_LENGTH (false) have different values." (slightly different cases exist). The policy can't be deployed. The issue happens when automatic policy builder is enabled on the source policy.
596367	Web App Security (ASM)	Signature sets - deploy to change "Update Date" from "Before"/"After" to "All" does not set the desired value. The deployment task succeeds, but the actual field value does not change. Additional evaluations will show differences. This is due to BIG-IP bug 596366. This problem will occur if the BIG-IP system is missing the fix for bug 596366.	Either install a fix to the BIG-IP device (if available) or split the deployment task into two - one that deletes the set, and another one that creates it with the desired value.
596787	Web App Security (ASM)	Exporting Web Application Security event logs fails silently without any errors in Web Application Security GUI when clicking the Select All option. Users cannot retrieve event logs in a CSV file on Chrome/Firefox. Issue happens when Select All option is used, which selects about 50 event logs per screen, however users are able to download CSV files for small number of selected ASM event logs in Chrome/Firefox.	Event logs can be exported in a CSV file by using Internet Explorer as the browser, or by selecting fewer records at a time.
606953	Web App Security (ASM)	The deployment of a new asm policy to a BIG-IP device is failing, and an "ASM subsystem error" appears in the BIG-IP's asm log. This was related to an intermittent BIG-IP bug 606285, where a previous attempt to delete a policy by the same name failed during the removal process.	If the deployment of a new asm policy to a BIG-IP device is failing, check the asm log on the BIG-IP. If an "ASM subsystem error" is shown, perform these two commands on the BIG-IP: tmsh list asm policy one-line \| wc -l tmsh list asm policy one-line all-properties \| wc -l if the numbers from the two queries do not match, we have a mismatch on the BIG-IP that needs to be corrected. To correct, remove the policy from bigip.conf: # tmsh save sys config # vim /config/bigip.conf remove this section ------- asm policy /Common/<policy_name> { encoding utf-8 } ------- save and quit # tmsh load sys config and re-try your deployment from the BIG-IQ.
611203	Web App Security (ASM)	Pushing a signature file to an active BIG-IP using 'active devices only' doesn't sync the file to the standby device the signature file isn't updated on the standby device although the BIG-IP sync indicator doesn't show any sync issues	select push to: 'All Devices' instead 'active devices only'
615170	Web App Security (ASM)	After rediscovering and importing a device into the ASM module, an unexpected configuration conflict appears in the Response Page sub-collection of an ASM policy. The difference noted between the configuration on the BIG-IQ and the BIG-IP being imported is an additional \r character string. The unexpected difference will persist on configuration imports until the configuration on the BIG-IQ is deployed to the target BIG-IP.	The next successful deployment operation to this device will reconcile the differences so that they will not appear on a rediscovery or redeployment.
615822	Web App Security (ASM)	If you attempt to deploy a change to an v11.5.4 BIG-IP where the change includes the migration of a manual-type signature set to a filter-based signature set, the deployment task will fail with the following error: error code:500 Can't use an undefined value as a HASH reference Deployment tasks will continue to fail while this type of change is listed in the change set being deployed to the v11.5.4 BIG-IP TMOS v11.5.4 experiences an issue when attempting to change the type signature set from manual to filter-based. This issue is tracked by BIG-IP issue number 615930.	Deployment tasks to this device will continue to fail until the change of signature set type is reverted or the signature set is replaced.
577761	Web Client Security (FPS)	If an Alert URL has spaces in it, such as "http://www.server.com/my site.hm", and you choose an Exact match on the word before the space ("my"), the alert incorrectly shows up as an exact match. Alert results may include false positive alert matches. In general, if the data that is being searched has spaces in it, exact match may return more results than expected with partial matches.
579528	Web Client Security (FPS)	This only occurs in a FireFox browser running on a Mac. When you right-click an alert inside an alert group, the "Filter 'related-to'" menu appears, but it typically disappears before you can select it. This behavior does not occur in any non-grouped view, such as the top-level views. Alert right-click 'Related to' searches cannot be done. On a MAC using the Firefox browser, you cannot right click while in a grouped view of alerts to do a related to search.	Use the advanced query filter and enter the fpm_guid value (found on the advanced tab of the alert's properties.
580676	Web Client Security (FPS)	It is possible to have a filter or search that matches alerts where you cannot find the string you searched for in any of the alert's fields. In these cases, the string is found in alert data that is not shown in the GUI. Although returned results have correctly matched the search criteria, it is not readily visible on GUI. On occasion some searches may return results that do not appear to match the search term.
594487	Web Client Security (FPS)	If log node restarts for some reason, transform rules and forwarding rules that are stored in cache on log node will be cleared. Transform rules and forwarding rules will not be applied to alerts until the next synchronization from BIG-IQ to LOG-IQ. For transform rules the synchronization frequency is 10 minutes and for forwarding rules it is 5 minutes.
606296	Web Client Security (FPS)	User defined alerts forwarding is not supported in 3.9.5 dashboard. They are only supported in 4.0+ LogIq cannot forward user defined alerts to 3.9.5 dahsboard, they will always be dropped at 3.9.5 dashboard.
613245	Web Client Security (FPS)	Import of large CSV file fails. User can not apply signatures, typically exported from SOC. Only when files are larger than about 8 MB	- Split the CSV file into multiple files less than 8MB. - Ensure split happens along line boundary, so, complete lines are in files. - Ensure CSV header (first line from original file) gets copied to each subsequent split file. That way each CSV file ha
615806	Web Client Security (FPS)	When an FPS Alert Forwarding Rule forwards alerts to a 4.X Versafe Dashboard, the alerts are categorized incorrectly on the Versafe Dashboard. They appear on the dashboard, but they appear in the wrong folders, so they are difficult to find. They appear in the correct folders in the BIG-IQ Console. Alerts are more difficult to find on a 4.X dashboard. This is not an issue for alerts forwarded to a 3.X dashboard, or for the alert views on the BIG-IQ Console. All of the following alert types go to the wrong folders in the 4.X Versafe dashboard: - Browser Automation (should go to Browser Automation) - Infected Users (should be ignored) - Referrer Checks (should go to Advanced Phishing) - Symbols Found (should go to Targeted Malware) - Image Checks (should go to Advanced Phishing) - CSS Checks (should go to Advanced Phishing)

Contacting F5 Networks

For additional information, please visit http://www.f5.com.

Additional resources

You can find additional support resources and technical documentation through a variety of sources.

The F5 Networks Technical Support web site: http://www.f5.com/support/
The AskF5 web site: http://support.f5.com/kb/en-us.html
The F5 DevCentral web site: http://devcentral.f5.com/
AskF5 TechNews

F5 Networks Technical Support

Free self-service tools give you 24x7 access to a wealth of knowledge and technical support. Whether it is providing quick answers to questions, training your staff, or handling entire implementations from design to deployment, F5 services teams are ready to ensure that you get the most from your F5 technology.

AskF5

AskF5 is your storehouse for thousands of solutions to help you manage your F5 products more effectively. Whether you want to search the knowledge base periodically to research a solution, or you need the most recent news about your F5 products, AskF5 is your source.

F5 DevCentral

The F5 DevCentral community helps you get more from F5 products and technologies. You can connect with user groups, learn about the latest F5 tools, and discuss F5 products and technology.

AskF5 TechNews

Weekly HTML TechNews: The weekly TechNews HTML email includes timely information about known issues, product releases, hotfix releases, updated and new solutions, and new feature notices. To subscribe, click TechNews Subscription, complete the required fields, and click the Subscribe button. You will receive a confirmation. Unsubscribe at any time by clicking the Unsubscribe link at the bottom of the TechNews email.
Periodic plain text TechNews: F5 Networks sends a timely TechNews email any time a product or hotfix is released. (This information is always included in the next weekly HTML TechNews email.) To subscribe, send a blank email to technews-subscribe@lists.f5.com from the email address you are using to subscribe. Unsubscribe by sending a blank email to technews-unsubscribe@lists.f5.com.

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

BIG-IQ Centralized Management

Summary:

Contents:

BIG-IQ Centralized Management 5.1.0

About BIG-IQ

New features

Screen resolution requirement

Browser support

BIG-IP compatibility

User documentation for this release

Software installation

Behavior changes

Fixed CVE issues in 5.1.0

Fixes

Known issues

Contacting F5 Networks

Additional resources

F5 Networks Technical Support

AskF5

F5 DevCentral

AskF5 TechNews

Legal notices

Have a Question?

About F5

Education

F5 Sites

Support Tasks

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

BIG-IQ Centralized Management

Summary:

Contents:

BIG-IQ Centralized Management 5.1.0

About BIG-IQ

New features

Screen resolution requirement

Browser support

BIG-IP compatibility

User documentation for this release

Software installation

Behavior changes

Fixed CVE issues in 5.1.0

Fixes

Known issues

Contacting F5 Networks

Additional resources

F5 Networks Technical Support

AskF5

F5 DevCentral

AskF5 TechNews

Legal notices

Have a Question?

Follow Us

About F5

Education

F5 Sites

Support Tasks