Configuring PTP with Arista AVD: Fabric-Wide Best Practices

Precision Time Protocol (PTP) is non-negotiable in media and financial networks, but configuring it consistently across every leaf, spine and endpoint is exactly the kind of repetitive task that automation should own. Arista AVD (Arista Validated Design) turns PTP deployment into a few declarative variables — enable it at the fabric, node-type or node level, and the role generates the entire per-interface configuration using Arista best practices. This article explains the AVD PTP model, the three supported profiles, automatic clock identity and priorities, monitoring thresholds, and how to handle PTP-only links between switches.

Why PTP Belongs in the Fabric Model, Not in a Script

PTP is unforgiving about consistency. Every device must agree on the profile, the announce/sync/delay-req intervals, the domain, and the transport. One leaf configured with the wrong sync interval does not merely have a slightly worse clock: it can win the best-master clock algorithm and pull the entire fabric onto a misconfigured grandmaster. Hand-editing that across 40 leaves and 8 spines is a recipe for drift between the intended design and what is actually deployed.

Declarative configuration solves it differently. The intent — “this fabric runs the AES67-R16-2016 profile, spines are preferred as grandmasters, and monitoring thresholds are these” — lives in group_vars. The AVD role expands that intent into per-interface EOS syntax, so the deployed configuration is a pure function of the variables. When you add a leaf, it inherits PTP automatically; when you change the profile, every interface changes together.

Prerequisites

• AVD 4.x or later with the arista.avd collection installed, and an inventory in the standard AVD structure (group_vars/FABRIC.yml, SPINES.yml, LEAFS.yml).
• EOS versions that support the chosen profile on every platform you intend to include. Hardware timestamping support varies by chip family; check the EOS PTP feature matrix for your switch models before enabling PTP fabric-wide.
• A grandmaster source. PTP needs an authoritative clock — a dedicated appliance, a GPS-disciplined server, or a switch acting as grandmaster with BMCA deciding. Decide which before you configure the fabric.
• A test fabric or a maintenance window. Enabling PTP changes the behaviour of routed spine-leaf interfaces, and on links where the underlay protocol does not run, you can drop routing adjacency by applying the wrong role.
• The legacy notation removed. Search your group_vars for uplink_ptp before you start; AVD expects the newer ptp dictionary.

Enabling PTP at Different Levels

Enable at fabric level (FABRIC.yml), per node type (SPINES.yml), or per node (LEAFS.yml):

# fabric level
ptp:
  enabled: true

# per spine node type
spine:
  defaults:
    ptp:
      enabled: true

# per leaf node
l3leaf:
  node_groups:
    - group: leaf1
      nodes:
        - name: leaf1a
          ptp:
            enabled: true

If legacy uplink_ptp: enable notation exists, remove it — otherwise the profile-specific interface configuration is not applied between leaf and spine.

The three levels exist for a reason, and using them well keeps the inventory small. A fabric-wide ptp.enabled: true covers the common case where every switch participates. Node-type level is the tool for mixed fabrics — for example enabling PTP on all spines but only on the media leaves. Node level is the escape hatch for a single device that must run a different profile, such as a leaf facing an audio console that only speaks SMPTE 2059-2.

PTP Profiles

AVD supports three profiles applied to all routed spine-leaf interfaces and PTP-enabled endpoint interfaces:

• aes67 — slow profile: sync interval 0 (1/s), announce interval 2, delay-req 0.
• smpte2059-2 — fast profile: sync interval -4 (16/s), announce -2 (4/s), delay-req -4.
• aes67-r16-2016 (default) — sync -3 (8/s), announce 0 (1/s), delay-req -3.

The interval values are logarithmic: each step of one halves or doubles the message rate. An interval of 0 means one message per second, -3 means eight per second, and -4 means sixteen per second. Higher message rates converge faster and hold tighter accuracy but consume more CPU and more link bandwidth, which is why the fast SMPTE profile is confined to media and broadcast networks while the default AES67 revision 2016 profile is the balanced choice for a general fabric.

Set the profile where you enable PTP — at fabric, node-type or node level — and it propagates to every interface the role generates:

ptp:
  enabled: true
  profile: smpte2059-2

Do not mix profiles across a single PTP domain. Two devices on the same link with different announce intervals will not form a stable relationship, and the symptom — one interface stuck in listening or uncalibrated — looks nothing like a configuration mismatch.

Automatic Priorities and Clock Identity

Priority 1 is derived from node type (spine=20, l3leaf=30, others=127), priority 2 from node_id modulo 256. Clock identity defaults to 00:1C:73 + priority1 hex + :00: + priority2 hex. Override manually per node, or disable auto identity to use the switch system MAC:

l3leaf:
  node_groups:
    - group: leaf1
      nodes:
        - name: leaf1a
          ptp:
            enabled: true
            priority1: 10          # grandmaster-facing leaf
            auto_clock_identity: false

The derived scheme is deliberate: because spine priority is lower than leaf priority, in a fabric with no external grandmaster the spines win the election and the leaves become followers. That produces a stable hierarchy with no manual tuning. Where an external grandmaster exists, the leaves connected to it are the ones that should be tuned — give those leaves a lower priority1 than the spines so they pass the grandmaster's clock into the fabric rather than competing with it.

auto_clock_identity: false falls back to the chassis MAC address. That is useful when your monitoring system already keys on MAC addresses, but it weakens the deterministic encoding, so pick one approach and apply it fabric-wide.

What AVD Actually Renders on the Device

Understanding the rendered output is what lets you debug the role instead of the switch. For a routed leaf-spine interface under the default profile, AVD emits roughly the following per-interface block:

interface Ethernet1
   description LEAF1A_ET1_TO_SPINE1_ET1
   no switchport
   ptp enable
   ptp profile aes67-r16-2016
   ptp sync-message interval -3
   ptp announce interval 0
   ptp delay-req interval -3
   ptp announce timeout 3
   ptp transport ipv4
!
ptp priority1 30
ptp priority2 11
ptp clock-identity 00:1C:73:1e:00:0b
ptp monitor threshold offset-from-master 250
ptp monitor threshold mean-path-delay 1500
ptp monitor threshold missing-message sync 3 sequence-ids

Two things are worth noting. First, the per-interface commands are derived from the profile; you never type the intervals by hand, which is precisely the consistency win. Second, the global commands (priority1, priority2, clock-identity) are produced once per device from the node name and node_id, so two leaves in different node groups cannot collide by accident.

Monitoring Thresholds

PTP monitoring is enabled by default when PTP is on, with sane defaults:

ptp monitor threshold offset-from-master 250
ptp monitor threshold mean-path-delay 1500
ptp monitor threshold missing-message sync 3 sequence-ids

These thresholds raise syslog and SNMP conditions when the clock drifts. The offset threshold is in nanoseconds and the mean path delay threshold is in nanoseconds as well, so 250 and 1500 are tight values suitable for media work — a fabric carrying only financial timestamps can relax them, while a ST 2110 deployment may need them tighter. Override them in the same ptp dictionary where you enabled PTP:

ptp:
  enabled: true
  monitor:
    enabled: true
    threshold:
      offset_from_master: 250

Wire these conditions into your monitoring platform before the fabric goes live. A silent offset breach is worse than an outright PTP failure, because everything keeps working until a synchronisation-dependent application produces wrong results.

PTP-Only Links and Endpoints

For switch-to-switch links used only for PTP (e.g. redundant grandmaster connectivity), use core_interfaces.p2p_links with include_in_underlay_protocol: false. For endpoints, PTP must be explicitly enabled per adapter; the default role is follower, and a grandmaster connection can run BMCA instead:

servers:
  - name: Blue-Grandmaster
    adapters:
      - type: server
        endpoint_ports: [ eth1 ]
        switch_ports: [ Ethernet5 ]
        switches: [ blue-spine1 ]
        ptp:
          enabled: true
          endpoint_role: bmca

The follower role is correct for a media or trading host that must never become a time source itself: it locks to whatever the fabric offers and never advertises its own clock. The bmca role is correct for a device that genuinely participates in the election — a grandmaster with a GPS input, or a redundant pair of grandmasters where the better one should win automatically.

Building and Deploying

Once the variables are set, apply the change the same way you apply any AVD update. Always generate before you deploy so you can read the diff:

# generate intended configurations
ansible-playbook playbooks/build.yml

# inspect the PTP blocks in the generated configs
grep -n "ptp" intended_configs/*/configs/*.cfg

# deploy
ansible-playbook playbooks/deploy.yml

Reading the generated configuration before pushing it is not optional for PTP. The role is capable of producing a syntactically valid configuration that applies the wrong profile to the wrong set of interfaces if a node-type override is misplaced, and the only cheap way to catch that is to grep the intended output. Commit the generated configs to git alongside the variables so every PTP change has a reviewable trace.

Verification on EOS

After deployment, verify at three levels: device role, interface participation and clock quality.

# overall clock state and role
show ptp
show ptp clock

# who the device is syncing to
show ptp parent

# per-interface participation and counters
show ptp counters all

# foreign masters seen on an interface
show ptp foreign-masters-record

On show ptp, confirm the device reports the role you designed — spines as grandmaster or boundary clock, leaves as boundary or follower, and the domain matching the profile. On show ptp parent, the grandmaster identity should be the device you chose, not an unexpected leaf. If the parent is a leaf when you expected a spine, the priority scheme is being overridden somewhere in the inventory.

Finally, check show ptp counters all for discarded or malformed messages. A steadily incrementing discard counter almost always means a profile or interval mismatch on one link, and it will show up long before the offset threshold alarm fires.

Troubleshooting and FAQ

The interface has no PTP configuration at all. Check that uplink_ptp was removed everywhere, that PTP is enabled at a level that covers this node, and that the link is one the role considers a routed spine-leaf interface. PTP-only links need the p2p_links treatment described above.

One interface stays uncalibrated. Compare the rendered per-interface block on both ends. Interval or profile differences between neighbours are the most common cause; a missing announce timeout or transport mismatch is the second.

The wrong device became grandmaster. Inspect priority1 values in the inventory. A node-level override that was meant for a grandmaster-facing leaf applied to a spine will invert the intended hierarchy.

Offset alarms fire but nothing is broken. Check the threshold values. Defaults that suit broadcast are unnecessarily tight for a general-purpose fabric and produce noisy alerting that teams learn to ignore.

Can PTP and NTP coexist? Yes, and they usually do. NTP disciplines the management plane and logging timestamps; PTP disciplines the data plane. They should be treated as separate services with separate monitoring. For a side-by-side comparison of the two protocols, see our PTP vs NTP explanation.

Does enabling PTP affect the underlay routing protocol? Not on a normal routed link, provided the role generates the interface correctly. On a PTP-only link with include_in_underlay_protocol: false, the interface is deliberately excluded from the underlay — make sure that is what you intend before deploying.

Where do I document the resulting configuration? In git, next to the inventory, and in your runbook. If your team also templates device configurations directly, see Ansible and Jinja2 templating for network configs for how that layer fits with AVD.

Related Reading on This Site

For more EOS operational practice, see the Arista EOS configuration cheat sheet and the MLAG run book.

原文链接：https://avd.arista.com/4.3/roles/eos_designs/docs/how-to/ptp.html