Feat(eos_designs): ESI Auto-Generation for EVPN AA Multihoming

jonxstill commented 2 years ago

Enhancement summary

Provide a mechanism by which ESIs for port-channels in EVPN AA Multihoming setups can be auto-generated.

Which component of AVD is impacted

eos_designs

Use case example

At present ESIs are manually-generated by the user and configured on the relevant port-channel, for example using the short_esi variable. There should be the option to auto-generate this, for example instead of:

  host1:
    rack: rack01
    adapters:
    - switch_ports: ['Ethernet3', 'Ethernet3']
      switches: ['leaf3', 'leaf4']
      <snip>
      port_channel:
        description: AA LAG to leaf3/4
        mode: active
        short_esi: 0003:0004:0003

We could use:

  host1:
    rack: rack01
    adapters:
    - switch_ports: ['Ethernet3', 'Ethernet3']
      switches: ['leaf3', 'leaf4']
      <snip>
      port_channel:
        description: AA LAG to leaf3/4
        mode: active
        esi_auto: true

Describe the solution you would like

The user should be able to choose from multiple options, for example:

Hash-based: Use a hash of hostnames, port-channel ID and potentially other data to create a unique but unintuitive ESI.
ID-based: Use switch IDs and Port-channel ID to produce a potentially conflicting but human-readable ESI. Use in conjunction with evpn_short_esi_prefix for site-uniqueness
User-defined: Use a user-provided template. While the user could override the two provided templates, having an obviously custom type may be more obvious.

The user should be able to set esi_auto_method: hash | id | user_defined. If set to user_defined, esi_auto_template must be set. auto_esi should be set to true on a port channel for this to be used.

Describe alternatives you have considered

N/A

Additional context

I will assign this to myself.

Contributing Guide

[X] I agree to follow this project's Code of Conduct

ClausHolbechArista commented 2 years ago

I think the model shoud be short_esi: auto so we can only have one or the other. The template should be part of our templates or maybe node_type_keys default tree, where we point to standard templates, but allow the user to override.

ankudinov commented 2 years ago

I'd also consider short esi auto as default. Means, if it's missing - it's auto.

ClausHolbechArista commented 2 years ago

I'd also consider short esi auto as default. Means, if it's missing - it's auto.

Good idea, but since we detect A/A vs. mlag based on the presence of this key, it will require some other logic changes, which might be too much for a minor release. Let's see when Jon get started.

aristanetworks / avd