Add data input variable to configure port-channel min-links in AVD

[lbarros-arista]

Enhancement summary

I am an Arista SE and for 1 of my top accounts in NL we would like to submit an enhancement request to add data input variable to configure port-channel min-links in AVD

Which component of AVD is impacted

eos_designs, eos_cli_config_gen, eos_validate_state

Use case example

The port-channel min-links command specifies the minimum number of interfaces that the configuration mode LAG requires to be active. If there are fewer ports than specified by this command, the port channel interface does not become active.

https://www.arista.com/en/um-eos/eos-port-channels-and-lacp#xx1152679

This can be used for many use cases for example guarantee a certain amount of BW to a service/server and if a link goes down bring the port channel down and trigger a failover.

It can also be used for when leafs connect with more than 1 link to the spine and a link downstream between the spine an an egress leaf/PE goes down. In this scenario when using eBGP for the underlay for example the loopback reachability would be unaffected by the link down event but the total BW available on that ECMP path would. Therefore from the ingress leaf/PE traffic would be hashed and load balanced equally and potentially dropped by the spine on the way to the egress leaf/PE.

Describe the solution you would like

It would be ideal if a new input variable could be created "min_links" perhaps under port-channel-interfaces that would add this functionality to AVD.

PE1(config-if-Po1)#port-channel min-links ?
<0-16> Minimum no of ports required up before bringing up a port-channel

Describe alternatives you have considered

Using eos_cli module under port_channel_interfaces and injecting CLI command.

Additional context

No response

Contributing Guide

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

[laxmikantchintakindi]

Completed eos_cli_config_gen changes in PR4790.

[ClausHolbechArista]

I think we can add this for eos_designs under connected endpoints adapters' port_channel key. But we would not use it for uplinks to spines, since we do not support port-channels there. The right solution for that scenario would be to use link-tracking groups.

[lbarros-arista]

I agree with adding support under port_channel_interfaces if possible (just as EOS would allow you to do with the CLI).

This would be more flexible than limiting it to connected endpoints adapters only. This is an optional parameter so customers depending on their design requirements can leverage this at will.

[gmuloc]

Some precision as I think there is some misunderstanding in your answer:

I agree with adding support under port_channel_interfaces if possible (just as EOS would allow you to do with the CLI).

The PR #4790 @laxmikantchintakindi mentioned has implemented exactly this for eos_cli_config_gen (the model you are pointing to). So you can already use it from devel.

@ClausHolbechArista is giving an option where it could be added in eos_designs as your initial issue was targeting three roles (quoting from there):

Which component of AVD is impacted
eos_designs, eos_cli_config_gen, eos_validate_state

Could you maybe clarify your use case and maybe indicate if the PR #4790 covers all of it?