Bug(eos_designs): Relax cross-device BGP peer IP reuse validation

[pmprado]

Issue Summary

Today, if a given bgp peer IP is used on device A and reused on device B, validation fails:

[WARNING]: [SJC13EXTLF01-A]: 'Validation Error: Marr-Managed-WAN[0].vrfs[0].bgp_peers': Values of Primary key 'ip_address'
are not unique as required.
[WARNING]: [SJC13EXTLF01-B]: 'Validation Error: Marr-Managed-WAN[0].vrfs[0].bgp_peers': Values of Primary key 'ip_address'
are not unique as required.

However, although not a recommended design, this is a valid config.
Currently, validation has to be run set to 'warning' and the user just ignores those messages increasing margin for errors.

Please allow IP reuse for BGP peerings across different devices.

Which component(s) of AVD impacted

eos_designs

How do you run AVD ?

Ansible CLI (with virtual-env or native python)

Steps to reproduce

On an MLAG pair with -A and -B peers, configure:

On -A:
        bgp_peers:
          - ip_address: 10.95.250.201  # svi 1608

On -B:
        bgp_peers:
          - ip_address: 10.95.250.201  # svi 1609

Relevant log output

TASK [arista.avd.eos_designs : Set eos_designs facts] *********************************************************************
[WARNING]: [SJC13MARLF01-A]: 'Validation Error: Marr-Managed-WAN[0].vrfs[0].bgp_peers': Values of Primary key 'ip_address'
are not unique as required.
[WARNING]: [SJC13MARLF01-B]: 'Validation Error: Marr-Managed-WAN[0].vrfs[0].bgp_peers': Values of Primary key 'ip_address'
are not unique as required.

Contributing Guide

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

[ClausHolbechArista]

So schema should be relaxed to not enforce uniqueness on primary key and then we need to ensure we use append_if_unique in the code.

[pmprado]

So schema should be relaxed to not enforce uniqueness on primary key and then we need to ensure we use append_if_unique in the code.

Makes sense - I take it that append_if_unique is device-specific?

[ClausHolbechArista]

So schema should be relaxed to not enforce uniqueness on primary key and then we need to ensure we use append_if_unique in the code.

Makes sense - I take it that append_if_unique is device-specific?

Correct.

[carlbuchmann]

So schema should be relaxed to not enforce uniqueness on primary key and then we need to ensure we use append_if_unique in the code.

@ClausHolbechArista I beleive the correct function name is append_if_not_duplicate can you confirm!