Bug ID 2201813: BIG-IP enforces maximum concurrent streams limit immediately over HTTP/2 connection

Last Modified: Mar 15, 2026

Affected Product(s):
BIG-IP LTM(all modules)

Known Affected Versions:
17.5.1, 17.5.1.2, 17.5.1.3, 17.5.1.4, 17.5.1.5

Opened: Jan 14, 2026

Severity: 3-Major

Symptoms

BIG-IP negotiates a number of concurrent streams over HTTP/2 connection per RFC requirement. It immediately enforces this limitation once the protocol is agreed and first SETTINGS frame is issued.

Impact

The client may send more requests than the limit set by BIG-IP over the established HTTP/2 connection and it causes the BIG-IP system to reset the extra streams. If Reset Stream Protection is enabled, it may result in the connection being shutdown by the BIG-IP system.

Conditions

-- BIG-IP virtual server with a http2 profile. -- A client connects to the virtual server and negotiates or starts HTTP/2 connection.

Workaround

None.

Fix Information

None

Behavior Change

On initial period until SETTINGS/ACK frame is arrived from the peer, TMM follows HTTP/2 RFC and assumes "unlimited" number of concurrent streams rather than enforcing the configured limit right away. If SETTINGS/ACK is not received, the timeout of 1 (one) seconds is used to start the stream concurrency enforcement. Until the enforcement starts, TMM queues stream-specific frames and "softly" enforces the limit to the configured one, allowing 128 frames and 128K of frame body (frame->length) at most.

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips