Enhance loopback_ip_range to Accept Start and End IP Addresses or Introduce loopback_ip_block or loopback_range_offset

[rrajpuro-anet]

Enhancement summary

Currently, the loopback_ip_range parameter in eos_designs network services requires IP addresses to be provided in a proper subnet boundary. This limitation restricts flexibility when defining loopback IP ranges for existing production networks being moved to AVD. This request is to:

1. Allow loopback_ip_range to accept IP addresses as a start and end address (not necessarily within a fixed subnet).
2. Alternatively, introduce a new key, loopback_ip_block, to specify the loopback IP range using a "start IP - end IP" format.

This change would improve configuration flexibility and align better with use cases requiring arbitrary IP ranges.

Which component of AVD is impacted

eos_designs

Use case example

In network designs, loopback IP addresses do not always align perfectly with subnet boundaries.

For example, consider the requirement to assign loopback addresses from 192.168.1.10 to 192.168.1.20 where:

loopback_ip_range expects the input to be a fixed subnet (e.g., 192.168.1.0/24), which is overly restrictive.
Manually managing and assigning addresses outside AVD's scope defeats automation efficiency.
By enabling support for start and end IP ranges or introducing a dedicated key like loopback_ip_block, this limitation can be resolved.

Describe the solution you would like

Modify the loopback_ip_range key to accept a ranges using a hyphenated format:

loopback_ip_range: 192.168.1.10-192.168.1.20

The framework should validate and ensure the provided range is enough for all devices.

Alternatively, add a new key, loopback_ip_block:

loopback_ip_block: 192.168.1.10-192.168.1.20

This change would allow dynamic and flexible assignment of loopback IPs without the constraints of subnet boundaries.

Describe alternatives you have considered

1. Overriding Loopback IP using eos_cli_config_gen.
   But this would mean that it should also take care of rd, router_id and Source NAT route entry.

Additional context

This feature request is for a customer that wants to manage their DC using AVD and are trying to move from manual configs to AVD.

Contributing Guide

• I agree to follow this project's Code of Conduct

[gmuloc]

@ClausHolbechArista it seems to be a duplicate of #2263

[ClausHolbechArista]

There is an overlap indeed, but one talk about a filter and the other about AVD itself, so I am ok with keeping both.