Fix/nonlinear dataplane downtime

[PriyanshTratiya]

Description of PR

Summary:
Fixes # (issue)
This PR addresses non‑linear dataplane downtime behavior observed in high‑scale BGP IPv6 scenarios when running the port and session flapping tests. When the number of connections to flap doubled, the dataplane downtime increased by 450x.

This change refines the tests and helper logic to ensure that downtime measurements:

• More accurately reflect real control‑plane and data‑plane outage intervals,
• Scale more predictably with load and iterations, and
• Avoid over‑counting or under‑counting downtime due to measurement artifacts and overlapping events.

Type of change

• [ x ] Bug fix
• Testbed and Framework(new/improvement)
• New Test case
  • Skipped for non-supported platforms
• Test case improvement

Back port request

• 202205
• 202305
• 202311
• 202405
• 202411
• 202505

Approach

What is the motivation for this PR?

While validating high‑scale BGP convergence, flap, and route‑programming tests, we observed that:

• Dataplane downtime did not scale linearly with:
  • The number of flap iterations,
  • The number of routes or neighbors.

These issues were traced to how the tests were executed sequentially while the PTF dataplane packet‑filtering/counter state was never cleared between runs. As a result, masks and counters kept accumulating over time, so that each subsequent run especially those with a larger number of ports to flap saw an artificially inflated dataplane downtime.

In other words, the measured non‑linear increase in downtime was caused by PTF dataplane state rather than actual BGP control‑plane behavior. The goal of this PR is to:

• Properly reset/clean relevant PTF dataplane state between runs,
• Ensure that measured dataplane downtime reflects only the real BGP and data‑plane behavior,
• Restore a linear and predictable relationship between test scale (routes/neighbors/iterations) and observed downtime.

How did you do it?

• Added logic to explicitly clear PTF dataplane state between runs, including:
  • Flushing or re‑initializing PTF packet filters used for counting traffic to the prefixes under test.
  • Resetting relevant PTF counters so that each run starts with a clean environment.
• Updated the test flow so that:
  • Each scale/iteration configuration first ensures PTF dataplane state is clean before starting flaps and dataplane measurements.
  • Dataplane downtime is computed only from counters and observations collected within the current run, avoiding any contamination from previous runs.
• Adjusted/factored helper utilities (where appropriate) so that the PTF cleanup is:
  • Centralized and reusable across the convergence, flap, and route‑programming tests,
  • Invoked consistently whenever a new test scenario or iteration is started.
• Enhanced logging around:
  • When PTF dataplane state is cleared,
  • Per‑iteration dataplane downtime measurements after the fix, so it is easy to verify that:
    • Counters are reset when expected, and
    • The resulting downtime scales linearly with the number of ports/routes/iterations, reflecting actual BGP and dataplane behavior.

How did you verify/test it?

• Re‑ran the high‑bgp convergence, flap, and route‑programming tests with the fixes applied:
  • Topology: t0-isolated-d2u510s2
  • Platform: Broadcom Arista-7060X6-64PE-B-C512S2
• Verified that:
  • Measured downtime per iteration is stable and scales predictably with load and iteration count.
  • Spurious spikes caused by measurement artifacts are eliminated and stay within millisecond compared to previous tens of seconds.

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[r12f]

straightforward change. will sign off, once comments are addressed.

[r12f]

Picking to 202412: Azure/sonic-mgmt.msft#982

[mssonicbld]

@PriyanshTratiya PR conflicts with 202511 branch

[weiguo-nvidia]

Hi @PriyanshTratiya

Could you help cherry-pick the fix to 202511 branch? Thanks

[PriyanshTratiya]

@PriyanshTratiya PR conflicts with 202511 branch

#22419