I was testing EVPN-MH on VyOS earlier (on 1.4.0-epa2 and 1.5-rolling). The control plane seems to be implemented completely, so there’s no problem there (proper EVPN routes are generated and propagated). The issue I’m encountering is there doesn’t appear to be any mechanism to push the es-system-mac to the member interfaces to allow for a proper multi-chassis etherchannel (MEC). This may just be me not being able to find the appropriate command to enable it, but I did a fair bit of digging and didn’t see it either in the CLI or in the source.
LACP will make the system-mac the first interface that gets added to the bundle (in Linux). You can’t add a member to the bond if it has a MAC set in the config, so the only way to properly set the value is to change the hw-id, which will allow the MEC to come up properly, but will break VyOS after a reboot. The interface you configure the hw-id on will be missing.
Without this, any downstream customer will effectively be in active-backup rather than active-active. The port-channel will have all but the first interface it receives a PDU from in a suspended state (or fall back to independent if downstream devices allows, which still breaks active-active).
Is there a randomly placed command that will allow for this, or is it something that needs to be added?
If there isn’t currently a mechanism, maybe there can be something at the interface level to accomadate this. Something like one of these:
set interfaces ethernet eth1 lacp-id aa:bb:cc:dd:ee:f0
set interfaces ethernet eth1 evpn-mh-id aa:bb:cc:dd:ee:f0
set interfaces ethernet eth1 es-system-mac aa:bb:cc:dd:ee:f0
Another option could be to update any member interfaces to the es-system-mac under the bond/evpn config (if present), but that would be less explicit for the user.