[DMA] add UMA and LMA min topo

[wenyiz2021]

This pull request introduces two new management network topologies—UMA and LMA—by adding their variable files and corresponding Jinja2 templates for both core and leaf devices. The templates support both converged (multi-VRF) and non-converged topologies, and implement detailed device and interface configuration logic, including BGP, interface, and management settings.

The most important changes are:

New Topology Variable Files:

• Added topo_uma.yml and topo_lma.yml with detailed definitions for VMs, DUT loopbacks, configuration properties, and per-device interface and BGP settings. These files describe the network layout and parameters for the UMA and LMA topologies. [1] [2]

Jinja2 Templates for Device Configuration:

• Added lma-core.j2, lma-leaf.j2, uma-core.j2, and uma-leaf.j2 templates. These templates generate EOS device configurations for core and leaf roles, handling both standard and converged (multi-VRF) topologies. [1] [2]

Support for Converged Topologies:

• All templates check for multi-VRF (converged) topologies and include a shared converged configuration (ceos_converged.j2) when appropriate, ensuring flexibility and reusability. [1] [2]

Device and Interface Configuration Logic:

• The templates implement logic for management VRF, interface addressing, BGP configuration (including confederations and peerings), MACsec support, and interface attributes such as MTU and LACP. [1] [2]

BGP Neighbor Handling Enhancements:

• In leaf templates, BGP neighbors are configured with allowas-in and other peer-specific settings to support advanced routing scenarios.

These changes collectively enable automated, flexible generation of EOS configurations for new UMA and LMA management network topologies.

Please provide following information to help code review process a bit easier:
-->

Description of PR

Summary:
Fixes # (issue)

Type of change

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

Back port request

• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605

Tracking issue/work item for backport/cherry-pick request (GitHub issue or Microsoft ADO):
Failure type:

Tested branch

• master
• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605
• N/A

Test result

Approach

What is the motivation for this PR?

How did you do it?

How did you verify/test it?

Any platform specific information?

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

Documentation

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

🟡 Not ready to approve

topo_uma_single_node_6ports.yml lacks explicit VM device_type properties, causing minigraph generation to misclassify LMA/M1 neighbors based on name heuristics.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

This PR introduces two new Ansible topology variable files under ansible/vars/ to enable single-node, 6-port DMA testbed configurations for Upper and Lower Management Aggregator scenarios, including VM VLAN mappings, BGP peerings (with confederation), and interface addressing.

Changes:

• Added topo_uma_single_node_6ports.yml defining an UpperMgmtAggregator DUT with RWA/LMA/M1 neighbor VM roles and BGP/interface details.
• Added topo_lma_single_node_6ports.yml defining a LowerMgmtAggregator DUT with UMA/M2/M3 neighbor VM roles, including explicit device_type properties for neighbor typing.

File summaries

File	Description
ansible/vars/topo_uma_single_node_6ports.yml	New UMA single-node 6-port topology; needs explicit neighbor device_type properties to avoid incorrect minigraph typing.
ansible/vars/topo_lma_single_node_6ports.yml	New LMA single-node 6-port topology with BGP confederation and neighbor role/device typing.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

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

[Copilot]

🟡 Not ready to approve

The new uma_*/lma_* topology names and the added EOS template filename don’t align with existing base_topo derivation/validation and template selection logic, so standard playbooks will reject or fail to render these topologies.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[Copilot]

🟡 Not ready to approve

The new UMA topo has no corresponding EOS templates and the LMA templates won’t be selected for cEOS due to base_topo template naming, causing provisioning failures.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (1)

ansible/roles/eos/templates/lma_single_node_6ports-leaf.j2:5

• The PR description says it only adds two new topology variable files, but it also introduces new EOS Jinja templates under ansible/roles/eos/templates/. Please update the PR description to include these additional deliverables so reviewers/operators understand the full scope of the change.

{# Converged (multi-VRF) topologies render the shared converged config; the
   stock body below is used unchanged on non-converged topologies. #}
{% if topo_is_multi_vrf | default(false) | bool %}
{% include 'ceos_converged.j2' %}
{% else %}

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

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

[Copilot]

🟡 Not ready to approve

topo_uma.yml currently lacks explicit device_type for the *LMA* VMs, which causes minigraph neighbor-type inference to misclassify them (and the PR description also doesn’t match the delivered filenames/scope).

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (6)

ansible/vars/topo_uma.yml:79

• This VM is named *LMA* but currently uses the generic leaf properties (no device_type), which makes minigraph device type fall back to name heuristics ('MA' in dev → MgmtSpineRouter). If this VM is intended to be a LowerMgmtAggregator neighbor, switch it to use the dedicated lma property set (with device_type: LowerMgmtAggregator).

    properties:
    - common
    - leaf

ansible/vars/topo_uma.yml:102

• This VM is named *LMA* but currently uses the generic leaf properties (no device_type), which makes minigraph device type fall back to name heuristics ('MA' in dev → MgmtSpineRouter). If this VM is intended to be a LowerMgmtAggregator neighbor, switch it to use the dedicated lma property set (with device_type: LowerMgmtAggregator).

    properties:
    - common
    - leaf

ansible/vars/topo_uma.yml:125

• This VM is named *LMA* but currently uses the generic leaf properties (no device_type), which makes minigraph device type fall back to name heuristics ('MA' in dev → MgmtSpineRouter). If this VM is intended to be a LowerMgmtAggregator neighbor, switch it to use the dedicated lma property set (with device_type: LowerMgmtAggregator).

    properties:
    - common
    - leaf

ansible/vars/topo_uma.yml:148

• This VM is named *LMA* but currently uses the generic leaf properties (no device_type), which makes minigraph device type fall back to name heuristics ('MA' in dev → MgmtSpineRouter). If this VM is intended to be a LowerMgmtAggregator neighbor, switch it to use the dedicated lma property set (with device_type: LowerMgmtAggregator).

    properties:
    - common
    - leaf

ansible/vars/topo_uma.yml:1

• PR description references new topology var files ansible/vars/topo_uma_single_node_6ports.yml and ansible/vars/topo_lma_single_node_6ports.yml, but the actual added files are ansible/vars/topo_uma.yml and ansible/vars/topo_lma.yml (and this PR also adds multiple EOS templates). Please either update the PR description to match the delivered filenames/scope, or rename the files/templates accordingly so topo selection remains clear.

topology:

ansible/vars/topo_uma.yml:51

• VM02LMA..VM05LMA will be inferred as MgmtSpineRouter in minigraph generation because their names contain the substring MA and no explicit device_type is set via properties. This likely mislabels LowerMgmtAggregator neighbors (see ansible/templates/minigraph_png.j2 heuristics) and can break tests/logic that rely on correct neighbor types. Consider adding a dedicated property (e.g., lma) with device_type: LowerMgmtAggregator and applying it to the LMA VMs.

This issue also appears in the following locations of the same file:

• line 77
• line 100
• line 123
• line 146

  core:
    swrole: core
  leaf:
    swrole: leaf

• Files reviewed: 6/6 changed files
• Comments generated: 0 new
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[yejianquan]

Reviewed this together with #26639, #26723, #26724 and #26750, since they form one dependency chain.

Confirmed correct

• The topo files land as the bare names topo_lma.yml / topo_uma.yml, which matches the lma / uma entries Apply redeploy fix for aggregators #26639 adds to the topologies list in ansible/veos. That list is consumed by exact match (ansible/verify_config.py:466, ansible/files/check_testbed_and_inventory_file.py:145), and check_vmfile_topologies() computes set(vmfile_topologies) - set(defined_topologies). So this PR should merge before (or together with) Apply redeploy fix for aggregators #26639 — if Apply redeploy fix for aggregators #26639 lands alone, lma/uma have no matching topo_*.yml and the validator reports them as invalid topologies.
• BGP confederation is symmetric and consistent between the two files: LMA dut_asn=64589 / dut_confed_asn=64582 / dut_confed_peers=64588, UMA dut_asn=64588 / dut_confed_asn=64582 / dut_confed_peers=64589.

Issue: topo_uma.yml declares no device_type, so its LMA neighbors render as the wrong device type

topo_lma.yml declares device_type for every neighbor role (UpperMgmtAggregator, MgmtSpineRouter, MgmtAccessRouter), but topo_uma.yml declares none. Without it, ansible/templates/minigraph_png.j2 falls through to the "guess the type from the VM name" chain, and hits this branch:

{% elif 'MA' in dev %}
{% set dev_type = 'MgmtSpineRouter'%}

dev here is the key from topology: VMs: (get_neighbor_eos() in ansible/library/testbed_vm_info.py reads vm_topology['topology']['VMs']), i.e. VM02LMA … VM05LMA. Those names contain the substring MA, so all four LMA neighbours are rendered as MgmtSpineRouter instead of LowerMgmtAggregator.

The other two happen to come out right by luck: VM01RWA matches the earlier 'RWA' branch, and VM06M1 contains no MA so it reaches the later 'M1' branch. And topo_lma.yml only escapes this because it sets device_type explicitly — its VM01UMA/VM02UMA keys contain MA too.

This is the same class of substring collision as the is_tor_dut fix in #26639 ("aggregaTOR" contains tor).

Suggested fix — split the leaf role so LMA and M1 can carry different device types, mirroring what topo_lma.yml already does:

  lma:
    swrole: leaf
    device_type: LowerMgmtAggregator
  m1:
    swrole: leaf
    device_type: MgmtLeafRouter

and point VM02LMA–VM05LMA at [common, lma] and VM06M1 at [common, m1].

This matters beyond the minigraph itself: #26724 and #26750 both branch on the neighbor device type, and they currently disagree on what a UMA's downstream peer is (see my comment on #26750). Settling topo_uma.yml first decides which of those two is correct.

Nit

The configuration keys here (VM01UMA, VM02LMA, …) don't follow the ARISTA01T1 / ARISTA001C0 convention used by the other topo files. Not a functional problem, just inconsistent — and it is what makes the 'MA' in dev collision reachable.

PR description

The template is still empty — no "Type of change" checked, and no test result. Worth filling in which testbed this was deployed on.

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

[Copilot]

🟡 Changes recommended

In topo_uma.yml, several VMs reference the generic leaf property set instead of the defined lma/m1 property sets, so the intended device_type values are never applied via props expansion.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (5)

ansible/vars/topo_uma.yml:109

• configuration_properties defines an lma property set (with device_type: LowerMgmtAggregator), but VM03LMA references the generic leaf property set instead, so the intended device_type never gets applied via props expansion.

    properties:
    - common
    - lma
    bgp:
      asn: 64589

ansible/vars/topo_uma.yml:132

• configuration_properties defines an lma property set (with device_type: LowerMgmtAggregator), but VM04LMA references the generic leaf property set instead, so the intended device_type never gets applied via props expansion.

    properties:
    - common
    - lma
    bgp:
      asn: 64589

ansible/vars/topo_uma.yml:155

• configuration_properties defines an lma property set (with device_type: LowerMgmtAggregator), but VM05LMA references the generic leaf property set instead, so the intended device_type never gets applied via props expansion.

    properties:
    - common
    - lma
    bgp:
      asn: 64589

ansible/vars/topo_uma.yml:178

• configuration_properties defines an m1 property set (with device_type: MgmtLeafRouter), but VM06M1 references the generic leaf property set instead, so the intended device_type never gets applied via props expansion.

    properties:
    - common
    - m1
    bgp:
      peer_in_bgp_confed: true

ansible/vars/topo_uma.yml:85

• configuration_properties defines an lma property set (with device_type: LowerMgmtAggregator), but VM02LMA references the generic leaf property set instead, so the intended device_type never gets applied via props expansion.

This issue also appears in the following locations of the same file:

• line 105
• line 128
• line 151
• line 174

    properties:
    - common
    - lma
    bgp:
      asn: 64589

• Files reviewed: 6/6 changed files
• Comments generated: 0 new
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[Copilot]

🟢 Ready to approve

Only a minor maintainability nit was found (unused config property block) with no functional impact on topology rendering.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (1)

ansible/vars/topo_lma.yml:58

• configuration_properties defines a leaf property set that is never referenced by any node’s properties list in this topology file, so it has no effect and can confuse future edits (only entries listed under configuration.*.properties are merged into props). Consider removing this unused block (or start referencing it explicitly from nodes if it’s intended to be used).

    device_type: UpperMgmtAggregator
  leaf:
    swrole: leaf
  m2:
    swrole: leaf

• Files reviewed: 6/6 changed files
• Comments generated: 0 new
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[yejianquan]

Re-reviewed after the latest push. The device_type fix looks good, but there's one functional gap I missed on the first pass.

Confirmed fixed

topo_uma.yml now declares device_type on every role, and the VM properties were updated to match (VM02LMA–VM05LMA → [common, lma], VM06M1 → [common, m1], VM01RWA → [common, core]). So nothing falls through to the name-guessing chain in minigraph_png.j2 any more and the 'MA' in dev collision is gone. The confederation block in lma-core.j2 also matches the existing implementation in lrh_min-core.j2 verbatim, so that's consistent with precedent.

Blocker: no routes will be announced on lma/uma testbeds

ansible/library/announce_routes.py has no lma / uma handling. Its topo dispatcher is driven by get_topo_type():

pattern = re.compile(
    r'^(t0-mclag|t0|t1|ptf|fullmesh|dualtor|t2|mgmttor|m0|mc0|mx|m1|c0|dpu|smartswitch-t1|lt2|ft2|lrh|urh)')
match = pattern.match(topo_name)
if not match:
    return "unsupported"

lma / uma don't match, so topo_type comes back as "unsupported" and main() falls to the final else:

else:
    module.exit_json(
        msg='Unsupported topology "{}" - skipping announcing routes'.format(topo_name))

ansible/roles/vm_set/tasks/announce_routes.yml is included unconditionally from add_topo.yml:429 (gated only on exabgp_action == 'start'), so add-topo on an lma/uma testbed will complete green while exabgp announces zero routes. It doesn't fail — it just silently skips.

That matters for the rest of the chain: the BGP tests being enabled in #26750 would come up with sessions established but no prefixes learned.

There's a light-touch precedent right there in the same function if a dedicated route generator isn't wanted yet:

# Temporarily map DRH topos to T2 routes
if topo_type in ['lrh', 'urh']:
    topo_type = 't2'

So either add lma|uma to the regex and map them onto an existing generator, or add fib_lma / fib_uma branches — but something needs to land, either here or in a companion PR before #26750.

Nit: dead leaf role in topo_lma.yml

  leaf:
    swrole: leaf

No device_type, and no VM references it any more — VM01/02UMA use core, VM03/04M2 use m2, VM05/06M3 use m3. Worth deleting, otherwise someone reusing it later silently drops back to the name-guessing path that this PR just fixed.

Observation, not a blocker: the two leaf templates are exact copies

lma-leaf.j2 and uma-leaf.j2 are byte-identical to each other and to the existing t2-leaf.j2 (same SHA256). lma-core.j2 and uma-core.j2 are likewise identical to each other, and differ from t2-core.j2 by exactly the 5-line confederation block.

To be fair this is already the convention here — t2-isolated-d128s2-leaf.j2, t2-isolated-d128s2-peer-leaf.j2, t2-single-node-min-leaf.j2 and t2-single-node-max-64p-leaf.j2 are all the same file too, and template lookup is "{{ base_topo }}-{{ props.swrole }}.j2" so a per-topo filename is required. So I'm not asking to change it. Just noting that if you'd rather not grow it by another ~640 lines, a one-line {% include 't2-leaf.j2' %} would work — these templates already use {% include %} for ceos_converged.j2.

PR description

Still the unfilled template. Given this adds a new topology, the "How did you verify/test it?" section and the testbed it was deployed on would be the useful part for reviewers.

[yejianquan]

LGTM

[mssonicbld]

Cherry-pick PR to msft-202603: Azure/sonic-mgmt.msft#1346