Possibility for link tracking (downstream) on l3leaf to l2leaf

adestis-mb commented 1 week ago

Enhancement summary

In the node definition of a l2leaf (or custom node with l2 services) there must be the possibility to define the link tracking behavior seen from the uplink switch in order to disable the connection if the uplink switch has a core isolation.

Which component of AVD is impacted

eos_designs

Use case example

When you have a pair of l3leafs where an another switch is connected (as l2 network service) as part of the fabric (e.g. via LACP MH), the connection from the l3leaf switch to the l2leaf switch does not go down when there is a core isolation on the l3leaf switch. In case of a core isolation of the parent switch the l2switch would still send traffic which would be dropped on the parent switch.

Describe the solution you would like

In the node definition of the child switch the link_tracking mechanism of the parent switch must be configurable to tell the parent that the connection to the client switch is a downstream connection and the parent should monitor a given uplink connection.

custom-node-type:
  nodes:
    - child-switch
      uplink_switches:
        - parent-switch1
        - parent-switch2
      link_tracking:
        name: UPLINK
        mode: downstream

Describe alternatives you have considered

With AVD 4.10.2 the only workaround we found was to add a network port configuration in the connected endpoints where a raw_eos_cli was added: raw_eos_cli: link tracking group UPLINK downstream

So the workaround looked like the following:

network_ports:
  - switches:
      - parent-switch1
      - parent-switch2
    switch-ports:
      - Ethernet33
      - Ethernet33
    raw_eos_cli: link tracking group UPLINK downstream

The problem with this solution is that the (ethernet) connection itself is down. Bringing the link up costs a lot of time compared with bringing up the lacp channel.

Additional context

No response

Contributing Guide

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

ClausHolbechArista commented 1 week ago

I think defining link-tracking for the l3leaf on the child l2leaf would be a bit hard to follow. Would it be good enough if implemented in the l3leaf vars to apply link tracking on all downlinks? I mean the link tracking group used would already be set in the l3leaf vars, so assigning that for downlinks in the same place seems logical to me. This would not allow for selective enabling of link-tracking to certain downlinks, so if that is needed, we will need to combine the ideas somehow.

Let me know what you think and if you need the selective enabling of this.

adestis-mb commented 1 week ago

For us it would be enough to define on the l3leaf what interfaces are downlink interfaces. Normally they are all. It could be that some interfaces should be excluded but this could then be done via endpoints / ports. If the definition in the endpoints / ports takes precedence over the default definition than that should be the best solution.

We are using just one group of uplink (called UPLINK). I cannot say s.th. about others which maybe require more than one group of uplink.

aristanetworks / avd