[action] [PR:26742] [DMA] add UMA and LMA min topo

[mssonicbld]

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

Signed-off-by: Sonic Build Admin sonicbld@microsoft.com

[mssonicbld]

Original PR: sonic-net/sonic-mgmt#26742

[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:
1 pipeline(s) were filtered out due to trigger conditions.