ClausHolbechArista
commented
1 week ago This does not follow the Arista best practices, so it would not be a general recommendation to configure this. It can have some adverse effects if you have multiple spines connected to each leaf like for "purple" devices or when having multiple spines per "color". We could add a special knob to configure this, but it would need to be enabled case-by-case. IMO a better solution here is to use PTP domains to separate the timing domains or avoid enabling PTP on connections to external networks.
geckigek
Enhancement summary
Implement an automatic configuration for PTP role assignment on spine downlink ports within the AVD fabric. Specifically, when PTP is enabled across the fabric, spine downlink ports should be automatically set as PTP masters, enhancing network stability and security by preventing unintentional synchronization with external PTP grandmasters.
Which component of AVD is impacted
eos_designs
Use case example
In a setup where the AVD fabric operates as a media network with a designated PTP grandmaster connected to the spine, we encountered a scenario where the spine inadvertently synchronized with an external PTP grandmaster from an adjacent network segment. This neighboring network segment is connected via a border leaf with a higher PTP priority set. While disabling PTP on the connection between the border leaf and the other network segment would address the issue, an automated approach would provide a more robust solution in dynamic environments.
Describe the solution you would like
It would be beneficial if AVD could support an automatic PTP security feature. Specifically, when PTP is enabled across the fabric, spine downlink ports should be automatically configured with a PTP master role. This would prevent unwanted synchronization with external grandmasters by reinforcing the AVD fabric's internal PTP hierarchy.
Describe alternatives you have considered
No response
Additional context
No response
Contributing Guide