Expose incoming/outgoing connection metrics and concurrent connection limits in F5XC

We would like to request enhanced observability capabilities in F5 Distributed Cloud (XC), specifically the ability to monitor incoming and outgoing TCP connection metrics, including:

  • Current active TCP connections (incoming/outgoing)

  • Concurrent TCP connections

  • Maximum TCP connection capacity / limits

  • Connection usage per CE node and per Virtual Site

Note: By "connections", we explicitly refer to TCP connections at the transport layer.

Currently, these metrics are not exposed in XC by design, which creates a significant visibility gap when trying to understand traffic behavior and capacity limits in production environments.

Use Case

In our deployment:

  • Customer Edge (CE) nodes use a single upstream IP (no SNAT pool).

  • The system relies on ephemeral TCP ports (RHEL default range: 32768–60999, ~28k ports).

  • Connection scaling depends heavily on TCP connection reuse, HTTP/2 multiplexing, and origin distribution.

Without visibility into:

  • Active TCP connections

  • Connection reuse efficiency

  • Connection exhaustion trends

…it becomes very difficult to determine whether we are approaching system or architectural limits (e.g., ephemeral port exhaustion, TCP connection saturation).

Problem Statement

At present, there is no direct way to:

  • Correlate traffic load with TCP connection usage

  • Validate scaling behavior of Virtual Sites

  • Proactively detect TCP connection exhaustion conditions

  • Troubleshoot performance degradation related to connection limits

Indirect metrics (e.g., dropped packets at infrastructure level) are insufficient and reactive rather than proactive.

Proposed Enhancement

We propose adding the following metrics to XC dashboards and/or API:

  1. Active TCP connections

    • Incoming (client → CE / WAF)

    • Outgoing (CE → origin)

  2. Concurrent TCP connections

    • Current concurrent connections per CE, per LB, and per Virtual Site

  3. TCP connection limits

    • Maximum supported TCP connections (per CE / per service)

    • Percentage of utilization

  4. Connection behavior insights

    • TCP connection reuse rate (keep-alive efficiency)

    • HTTP/1.1 vs HTTP/2 usage (as it affects TCP consumption)

    • Connection churn rate (new vs reused TCP connections)

  5. Granularity

    • Per-site

    • Per-virtual site

    • Per-origin pool

Business Impact

This feature would provide:

  • Better capacity planning

  • Improved troubleshooting and RCA

  • Reduced risk of ephemeral TCP port exhaustion

  • Enhanced confidence when scaling with Virtual Sites and ECMP

  • Alignment with industry-standard observability (e.g., HAProxy /metrics)

Additional Context

In traditional solutions (e.g., HAProxy), metrics such as:

  • Current TCP sessions

  • Max TCP sessions

  • Connection rates

…are readily available and are critical for operating large-scale edge deployments.

Providing similar TCP-level visibility in XC would significantly improve operational capabilities.

  • Guest
  • May 11 2026
  • Attach files