Addition of prober_typer knob of MUX_CABLE as part of golden config

[harjotsinghpawra]

Description of PR

Summary:
Prober_type knob was added in MUX_CABLE,now we needed an option to run mgmt runs with software prober or hardware prober for any run on dualtor.

How to enable it :

• conf-name: docker-ptf
  group-name: sonic_cisco
  topo: t0
  ptf_image_name: docker-ptf-titan
  prober_type: hardware
  ptf: docker-ptf
  ptf_ip: 192.168.122.78/24
  ptf_ipv6: fc0b::1/64
  server: server_1
  vm_base: VM0100
  dut:
  • titan-01
    inv_name: lab
    auto_recover: 'True'
    comment: Test ptf titan

Fixes # (issue)

Type of change

• Bug fix
• [X ] 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
• 202605

Approach

What is the motivation for this PR?

This PR is to add support for prober_type knob enable or disable in golden_config

How did you do it?

added prober_type: <hardware/software> to testbed.yaml
specific config will be added to golden_config_db.json
which will eventaully go to config_db.json using minigraph_override

How did you verify/test it?

Ran sanities with this option enabled and then disabled. It was generating the right golden_config

Any platform specific information?

Default value of this prober_type will be software .if nothing is added in testbed.yaml then no need to add this as default is already software.

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).

[zjswhhh]

Hi @bingwang-ms - please help merge.

[zjswhhh]

Hi @harjotsinghpawra - what the plan for this PR? Do we want to resolve the conflict and merge.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[zjswhhh]

Hi @harjotsinghpawra - can you add a sample kvm testbed in testbed.yaml with the prober_type field.

[Ndancejic]

/azpw run

[mssonicbld]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[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).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[harjotsinghpawra]

@anders-nexthop Done , can you please review thanks .

[anders-nexthop]

Thanks for the rebase — the prober_type plumbing reads well and the MUX_CABLE/PORT injection looks right. Two inline questions/nits, plus one ask:

@zjswhhh earlier asked for a sample testbed.yaml entry with the prober_type field — it doesn't look like that made it into the diff yet. Could you add one so others enabling this have a reference?

— anders-bot (AI-assisted, on behalf of @anders-nexthop)

[anders-nexthop]

buffer_model="traditional" — intentional drop for dualtor? Before this PR, dualtor fell through to the else branch → generate_default_init_config_db(), which sets DEVICE_METADATA.localhost.buffer_model = "traditional" — the same path plain t0/t1 take, so they keep it. Routing dualtor through this new method instead means dualtor diverges from its t0/t1 siblings' buffer model. The two other split-out generators (generate_full_lossy_golden_config_db, generate_smartswitch_golden_config_db) deliberately re-assert traditional, so if dualtor needs the static buffer model like t0/t1, this method should set it too (right after the DEVICE_METADATA copy). Was the drop intended?

[harjotsinghpawra]

You are right first i skipped it thinking that by default the type is traditional ,but we check the actual metadata value in some scripts so addedit back.

[anders-nexthop]

Typo: require=False should be required=False — require isn't a valid argument_spec key (every other entry here uses required=). On stricter ansible-core this can raise on the unknown key; where it's tolerated it silently means no required constraint is applied (harmless here since default=None, but worth fixing).

[harjotsinghpawra]

Fixed

[anders-nexthop]

@harjotsinghpawra I found a couple minor things, please address them as you see fit and then I can merge the PR.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[harjotsinghpawra]

@anders-nexthop Jing suggested that because some kvm tests were failing when i initially raised, and there is no sample config for lit or filterleaf . But i have added sample config for refrence

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[harjotsinghpawra]

@anders-nexthop can we cherry pick it for 202605 ?

[mssonicbld]

This PR has backport request for branch(es): 202605.
Added label(s) for branch(es) 202605.

_{---Powered by SONiC BuildBot}

[StormLiangMS]

@harjotsinghpawra — this PR is labeled Request for 202605 branch, but the following required information is still missing:

• linked GitHub issue or ADO work item
• 202605-specific image/test result evidence

Please add the missing information to the PR description. Tracker details should cover day-one/regression status, affected branch/image/platform/test, and why 202605 needs the fix; validation should identify the tested 202605 image and include the result or result link.

[StormLiangMS]

Hi @harjotsinghpawra,

Could you please clarify whether this PR is a must-have cherry-pick for the 202605 branch?

Current evaluation

• Classification: Platform/HWSKU enablement or config
• Bug fix: No
• Recommendation: NO
• Rationale: Adds optional dual-ToR prober_type golden-config plumbing and a lab example, not a defect fix. No linked issue or 202605 validation; the new dual-ToR generator and sample-specific config increase cherry-pick risk.

If this is required for 202605, please reply with the branch-specific failure or impact, required dependencies, and 202605 validation results.

If there is no response by September 2, 2026, the Request for 202605 branch will be rejected based on the evaluation above.

[mssonicbld]

This PR has backport request label(s) for branch(es): 202605, but is missing required test information. Please make sure you tick the tested branch(es) in the Tested branch section and provide test evidence (e.g., 202605: <test result>) in the Test result section as well in your PR description.

_{---Powered by SONiC BuildBot}