Feat(eos_designs): Support EVPN multihoming features link-tracking and lacp port-id range

[tgodaA]

Change Summary

The PR #1285 and #1301 were related to the eos_cli_config_gen role and the same features were supported in eos_designs now. These features are related to the EVPN multihoming, 1) Link-Tracking Group 2) LACP Port-id

Design Guide Page 16 and 17

Related Issue(s)

Fixes #1043 #1074

Component(s) name

arista.avd.eos_designs

Proposed changes

Need to support: 1) Link tracking groups 2) Different Lacp Port-id in different vtep groups

A) Fabric variables:
To create Link tracking groups under any type of node as well as adds all the switch uplink interfaces as upstream interfaces in that group:

<node_type_keys>:
  default:
    link_tracking:
      enabled: < true | false >
      # Optional default group name -> "LT_GROUP1", recovery_delay -> 500
      groups:
        - name: < tracking_group_name >
          recovery_delay: < 0-3600 | default -> 500 >
          links_minimum: < 1-100000 >

Lacp Port-id range must be set in Vteps only (l3leaf) to make sure the end-point can differentiate the different switches(l3leafs), it is connected to in the ES-LAG group.
To support different lacp port-id in different Vtep groups:

<node_type_keys>:
  default:
    lacp_port_id_range:
      enabled: < true | false | default -> false >
      # Recommended size > = number of ports in the switch.
      size: < 1-65535 | default -> 128 >
      # Offset is used to avoid overlapping port-id ranges of different switches | Optional
      # Useful when a "connected-endpoint" is connected to switches in different "node_groups".
      offset: < offset_for_lacp_port_id_range | default -> 0 >

B) On connected-endpoints we set up the link tracking group downstream interfaces:

link_tracking:
  enabled: < true | false >
  # The default group name is taken from fabric variable of the switch, link_tracking.groups[0].name with default value being "LT_GROUP1".
  # Optional if default link_tracking settings are configured on the node.
  name: < tracking_group_name >

How to test

Molecule

Checklist

User Checklist

• N/A

Repository Checklist

• My code has been rebased from devel before I start
• I have read the CONTRIBUTING document.
• My change requires a change to the documentation and documentation have been updated accordingly.
• I have updated molecule CI testing accordingly. (check the box if not applicable)

[tgodaA]

I have added new molecule scenario. Need some help with the review. If everything is good, let me know how to add it to the workflow. Thank you!

[ClausHolbechArista]

I have added new molecule scenario. Need some help with the review. If everything is good, let me know how to add it to the workflow. Thank you!

Please do not add extra molecule scenarios. We are trying to get fewer, since the CI runtime is getting very long (and expensive). Best would be to just add the data you need in a hostvars file and add the device(s) under the unit_test scenario. Avoid using any existing groups. Just add a new UNIT_TESTS group under all and supply all the required vars in hostvars. Ping me if we should work this out together.

[tgodaA]

@ClausHolbechArista , I saw an example of UNIT_TESTS in eos_designs_unit_tests. But for the multihoming example, I need the whole spine-leaf-end_point architecture to test link_tracking_groups and just a l3leaf to test lacp_port_id_range. But I am working to move this to eos_designs_unit_tests.

[tgodaA]

@ClausHolbechArista let me know if these artifacts looks good to you. I will try to remove few more knobs in the example to make it a unit test only for those new knobs.

[ClausHolbechArista]

I think we should default to 0 / no delay. If this is seconds, it will have severe impacts on the network.

[tgodaA]

No, recovery_delay is required as far as I understand. 500 was the value used in document. We are allowing the BGP to come up and then LAGs to work to avoid the traffic arrival before the network is actually up. I understand you are presenting the generic config, but I think mostly this knob is going to be used for multihoming as far as I guess.

[tgodaA]

Even for a regular use case, I think there should be a delay to allow for route convergence unless if static routing is used.

[ClausHolbechArista]

For l3 devices (check switch.underlay_router) I think the default should be 300 to match the default mlag reload delay. For pure l2 devices where we just have a port-channel uplink, IMO the delay should be minimum. Maybe 10 seconds. Just for spanning-tree to settle.

[tgodaA]

Tested link_tracking on a l2leaf. It works now. Couldn't test on SPINE though!

[ClausHolbechArista]

For l3 devices (check switch.underlay_router) I think the default should be 300 to match the default mlag reload delay. For pure l2 devices where we just have a port-channel uplink, IMO the delay should be minimum. Maybe 10 seconds. Just for spanning-tree to settle.

[tgodaA]

Mlag reload delay:

Here is the info I found on https://www.arista.com/en/um-eos/eos-multi-chassis-link-aggregation?searchword=mlag%20timer

---

---

[ClausHolbechArista]

LGTM! Thank you for this great contribution.

[carlbuchmann]

LGTM!