903905-5 : Default configuration of security mechanism causes memory leak in TMM

Component: REST Framework and TMOS Platform

Symptoms:
Over time, memory is allocated by the TMM processes for use as 'xdata' buffers, yet this memory is never de-allocated; it is leaked and becomes unusable. Eventually a disruption of service occurs.

Conditions:
-- The BIG-IP system has been running for 8 weeks or longer without a system restart.

-- The BIG-IP system's internal risk-policy subsystem (used by the security feature modules) has not been configured to communicate with an external risk-policy server.

-- In a vCMP configuration, the BIG-IP 'host' instance is always susceptible, since no security features can be configured in its context.

Impact:
Traffic disrupted while tmm restarts.

Workaround:
None.

Fix:
Default configuration of security mechanism no longer causes memory leak in TMM.

1037853-1 : Users assigned to a role that is not Administration can see the option for scheduling a report, but cannot schedule it

Component: AppIQ

Symptoms:
Users assigned to a non-Administrative role can see the scheduling option for reports, but cannot create a schedule.

Conditions:
When a non-Administrative role is assigned to a user and they attempt to create a report schedule.

Impact:
Unable to schedule a report.

Fix:
Users assigned to a role that does not have permission to schedule reports will no longer see the report schedule option.

1035093-2 : Assigning a utility license to an unmanaged device

Solution Article: K41117246

Component: REST Framework and TMOS Platform

Symptoms:
When attempting to assign a utility license to an unmanaged BIG-IP device, BIG-IQ returns the following error:

"The system returned an unexpected error (400 bad request). Error while assigning license to unmanaged device."

Conditions:
When you attempt to assign a utility license to an unmanaged BIG-IP device.

Impact:
You cannot assign utility licenses to unmanaged BIG-IP devices.

Workaround:
None.

Fix:
This is fixed in BIG-IQ version 8.1.0.1. You can now assign utility licenses to unmanaged BIG-IP devices.

1034825-2 : Discovering BIG-IP device error - Duplicate item. Key already exists

Component: BIG-IQ Configuration - Infrastructure

Symptoms:
When adding/discovering BIG-IP devices, configured in a device service cluster, BIG-IQ returns an error similar to the following:

Failed to synchronize clustered devices; reason: Device sync failed from device bigip1.example.com (10.30.40.100) to device bigip2.example.com (10.30.40.101): working-config target object sender failed: Duplicate item. Key already exists: partition : Common, deviceReference : /mgmt/shared/resolver/device-groups/cm-adccore-allbigipDevices/devices/f9c47c54-a1d5-5a65-97f2-334457840585, name : HTTPServer.

Conditions:
This happens when:

1) You add a BIG-IP device that is configured in a device service cluster.
2) More than one object in the BIG-IP configuration has the same name.

For example, both an LTM virtual server and network route shared the name: HTTPServer

Impact:
BIG-IQ is unable to discover the BIG-IP device.

Fix:
BIG-IQ can now manage BIG-IP device objects with same name in its configuration.

1034113-2 : RADIUS authentication fails

Component: REST Framework and TMOS Platform

Symptoms:
BIG-IQ fails to authenticate users with RADIUS.

Conditions:
When BIG-IQ is configured to use RADIUS for authentication and the RADIUS server attributes are appended with Unicode characters.

Impact:
Users are unable to log in to BIG-IQ because RADIUS authentication failed.

Fix:
This issue is now fixed and RADIUS authentication works as expected.

1032641-6 : BIG-IQ analytics performance is reduced when receiving high rate of DNS statistics from BIG-IP

Component: AppIQ

Symptoms:
When BIG-IQ receives a large number of DNS statistics from a BIG-IP (From appiqagent at DCD), BIG-IQ logs the following error:

2021-05-26 20:09:20,009 INFO c.f.a.a.r.ReactorPipeline [XNIO-2 task-45] Source buffer high watermark reached (available-capacity: 5905, max-capacity: 65536, usage: 90.99%, please retry later
2021-05-26 20:09:20,009 WARN c.f.a.a.c.RawDataAPIController [XNIO-2 task-45] Sending HTTP response 504 Gateway Timeout with Retry-After : 3434ms

Conditions:
One or more BIG-IP devices are configured to send DNS statistics.

Impact:
When the high-water mark level is too high, statistics are lost.

Fix:
This issue has been resolved and DNS statistics are properly reported.

1031321-4 : BIG-IQ analytics becomes unresponsive

Component: AppIQ

Symptoms:
BIG-IQ analytics become unresponsive BIG-IQ logs errors in /var/log/elasticsearch

Conditions:
BIG-IQ configured with Data Collection Devices (DCD)s.

Impact:
Analytics does not report as expected.

Workaround:
Perform the following on each DCD in your configuration:

1. Edit /var/config/appiq/agentmanager/config/application-bigiq.yml

For"indexes-overflow-protection" change the "initial-delay" from 7200000 to 0.

2. Save the configuration.

3. Restart appiqagent to reload the configuration by typing:

bigstart restart appiqagent

1028329-3 : Filter query in AFM rule search is slow

Component: BIG-IQ Network Security

Symptoms:
When there are a high number of referenced items, BIG-IQ might take more time to filter for AFM rules in rule lists or policies in environments with high load.

Conditions:
1. Navigate to Configuration >> Security >> Network Security >> Rule Lists >> Rule List Item
2. In the "Filter" search area enter a search string and search

Impact:
Performance is degraded.

Workaround:
Filtering might be slow, but BIG-IQ provides the correct results.

Fix:
Filtering performance is now improved on BIG-IQ.

1021149-4 : Elasticsearch can become unhealthy after adding a Data Collection Device (DCD)

Solution Article: K68489751

Component: AppIQ

Symptoms:
Elasticsearch displays as unhealthy and logs messages similar to the following in /var/log/elasticsearch/eslognode.log

2020-07-14T00:04:13,292][INFO ][o.e.d.z.ZenDiscovery ] [xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx] master_left [{xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx}{xxxxxxxxxxx}{xxxxx}{192.0.2.3}{192.0.2.3:9300}{zone=default}], reason [failed to ping, tried [3] times, each with maximum [30s] timeout]
[2020-07-14T00:04:13,293][WARN ][o.e.d.z.ZenDiscovery ] [xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx] master left (reason = failed to ping, tried [3] times, each with maximum [30s] timeout), current nodes:

Conditions:
There are long-lived TCP connections on port 9300 between BIG-IQ and data collection devices (DCD). Those connections send keepalive probes after being idle for 299 seconds. If an intermediate device idle-times out this TCP connection in less than 299 seconds, the ES cluster will experience stability problems.

Impact:
ElasticSearch Cluster is not healthy.

Workaround:
On each BIG-IQ and DCD device, perform the following steps:

1. Edit the file /etc/bigstart/scripts/elasticsearch and modify the following setting to meet the needs of the environment:

sysctl -w net.ipv4.tcp_keepalive_time=299 \
net.ipv4.tcp_keepalive_intvl=60 \

2. Set net.ipv4.tcp_keepalive_time to the number of seconds a connection is idle before keepalives are sent.

3. Set net.ipv4.tcp_keepalive_intvl to the interval between keepalives

Example values that work in most environments:

sysctl -w net.ipv4.tcp_keepalive_time=20 \
net.ipv4.tcp_keepalive_intvl=20 \
 
4. To set the values type the following commands:

Note: The values set in /etc/bigstart/scripts/elasticsearch take effect on the next boot, but will not persist after an upgrade.

sysctl -w net.ipv4.tcp_keepalive_time=20
sysctl -w net.ipv4.tcp_keepalive_intvl=20

See also https://support.f5.com/csp/article/K68489751

Fix:
This issue is fixed and the DCD no longer becomes unhealthy.

1016169-3 : Installation of BIG-IQ version 8.0.0 EHF fails

Component: REST Framework and TMOS Platform

Symptoms:
When installing BIG-IQ 8.0.0 EHF, the installation fails and BIG-IQ returns the following error in /var/log/restjavad.0.log.

"...Failed to run pre upgrade hook due to 'mount: /dev/loop0 is write-protected, mounting read-only
mount: /dev/loop1 is write-protected, mounting read-only
Querying for em_rest_java RPM file in ISO failed."

Conditions:
Installation of BIG IQ 8.0.0 EHF build fails if EHF ISO does not have em_rest_java RPM as part of ISO.

Impact:
Installation fails.

Workaround:
N/A

Fix:
This issue is now fixed and package validation is done as per expectations.

• The F5 Networks Technical Support web site: http://www.f5.com/support/
• The AskF5 web site: https://support.f5.com/csp/#/home
• The F5 DevCentral web site: http://devcentral.f5.com/

Generated: Mon Aug 9 15:06:27 2021 PDT

Copyright F5 Networks (2021) - All Rights Reserved