Precision Time Protocol (PTP) management messages are general messages sent to PTP-enabled switches on the data plane. On Arista switches, its behavior depends on the configured PTP mode. 

Until now, all PTP packets received on Arista switches with PTP boundary mode enabled will automatically be sent to

This article provides a general introduction to Precision Time Protocol (PTP) supported within EOS. PTP is aimed at distributing time with sub-microsecond accuracy. PTP support is based on the IEEE-1588 specification for version 2 of the protocol. 

PTP 1-step Boundary Clock (or 1-step BC) is similar to 2-step BC in function but doesn’t send the PTP Follow_Up message. The timestamp present in the PTP Follow_Up message’s preciseOriginTimestamp field is sent in the PTP Sync message’s originTimestamp field along with a non-zero correctionField. This allows us to support more PTP master ports because the control plane does not need to generate PTP Follow_Up messages anymore. PTP 1-step BC supports all the existing features supported by 2-step BC like G8275.1 profile, G8275.2 profile, etc unless otherwise specified in the limitations.

This brief TOI describes a small update made to Arista’s implementation of the Best Master Clock Algorithm (BMCA),

Media Access Control Security (MACsec) is an industry-standard encryption mechanism that protects all traffic flowing on the Ethernet links. MACsec is based on IEEE 802.1X and IEEE 802.1AE standards.

This feature allows users to view most recent history of offset from master, mean path delay and skew values via CLI

Since the introduction of PTP Monitoring feature[1], PTP is capable of recording recent metrics for offset from

This TOI document describes the supported Precision Time Protocol (PTP) functionality on the CCS-750X platforms. Due to the nature of the hardware for these products, the supported PTP functionality and interoperation with other features may differ from other Arista products.

The `ptp forward-v1` command configures the switch to forward Precision Time Protocol version 1 packets as regular multicast traffic. By default, when PTP is enabled and PTPv1 packets are received on the PTP enabled interfaces, these packets are trapped by the CPU, logged and discarded.

This feature enables L3 reachability for the PTP on the switch using one or more shared “Loopback” interfaces.

This feature allows configuring a per-port PTP domain number, which may be different from the global PTP domain number, which will apply to PTP messages sent or received on that port. With this configuration applied, transmitted messages will contain the port-specific domain number and received messages will be accepted if they contain the port-specific or global domain number.

The PTP Boundary Clock advertises time based on its local clock, which is counting from an unsynchronized initial value. Hence a free running Boundary Clock would advertise PTP downstream based on counting from an unsynchronized initial value. The GrandMaster, with access to GPS, is however Temps Atomique International (TAI) based. Hence Boundary Clock, which was originally based on unsynchronized initial value, post synchronization with the GrandMaster becomes TAI based. This causes the Boundary Clock’s time and hence PTP advertised downstream, to change drastically.

This article describes the usage of the ptp free-running source clock command, which selects a time source used by a switch running the Precision Time Protocol (PTP) while it is in a free-running state.

From the Precision Time Protocol (PTP) perspective, Multi Chassis Link Aggregation (MLAG) peers are two physical

Synchronous Ethernet (SyncE) provides support for frequency synchronization over Ethernet between devices traceable to an external frequency reference, like a primary reference clock, as specified in ITU G.8261.

This feature makes the PTP agent aware of VLANs, running with a single Best Master Clock Algorithm (BMCA). It allows