Open carlbuchmann opened 1 year ago
I would suggest picking up on some global construct instead of having to parse all connected endpoints and detect the relevant vlans. Especially since this would give configuration changes under router bgp
just because someone added a VLAN to a trunk or moved an endpoint.
Checking again, we do not have any coverage of dot1x outside of the connected endpoints, so when adding that, it would be natural to also cover this.
dot1x can also be configured as an interface profile for consistency across ports.
This issue is stale because it has been open 90 days with no activity. The issue will be reviewed by a maintainer and may be closed
This issue is stale because it has been open 90 days with no activity. The issue will be reviewed by a maintainer and may be closed
I have a customer facing the same issue. Current work-around: _redistribute dot1x__ is set up with raw cli in AVD. @ClausHolbechArista: I agree to you. A global knob to enable redistribution of static (dot1x) MAC into EVPN on the fabric would be sufficient. Having this configured on leafs/vlans without dot1x would not harm the dynamic redistribution.
This issue is stale because it has been open 90 days with no activity. The issue will be reviewed by a maintainer and may be closed
When dot1x is "turned on", MACs go from being DYNAMIC learned to STATIC via dot1x learned. Without the "redistribution dot1x" under the mac-vrf, these MACs don't get shared with remote VTEPs.
The proposed solution would be to automatically configure redistribution dot1x when configured on an endpoint.