PTP IEEE 1588 Boundary Clock Configuration Guide

Phase and time synchronisation stopped being a telecom-only concern the moment packet networks started carrying 5G fronthaul, financial timestamps and distributed tracing. IEEE 1588 PTP solves it, but only if the clock roles and profiles are designed rather than copied. This guide explains ordinary, boundary and transparent clocks, how the best master clock algorithm decides who leads, the difference between the full-timing-support G.8275.1 profile and the partial-support G.8275.2 profile, and the configuration and verification commands for a boundary clock on a modern switch.

Clock types and why they matter

• Ordinary clock - one PTP port, either a grandmaster (source of time) or a slave. A grandmaster-capable ordinary clock is the tree root.
• Boundary clock - multiple PTP ports sharing one local clock. Each port individually becomes master or slave, and PTP messages terminate in the protocol engine instead of being forwarded. This is what removes the accumulated switch delay that a plain network device would introduce.
• Transparent clock - forwards PTP messages like a normal switch but measures residence time and writes a correction into the packet. Useful where full boundary clock support is not available, but it does not regenerate timing.

Telecom profiles

G.8275.1 provides full timing support: every device on the path participates in PTP, hop-by-hop, with an alternate BMCA selecting the grandmaster from clock class, accuracy, offset-scaled log variance, priority2 and local priority. It is Ethernet-only and multicast-only, with announce at 8 packets per second and sync/delay-request at 16 per second by default. G.8275.2 provides partial timing support: not every device must run PTP, transport is PTP over IPv4/IPv6 unicast, and clocks are typically T-BC or T-TSC attached to a loopback-style virtual port rather than a physical one.

Configuring a boundary clock

switch(config)# ptp clock boundary domain 0 profile default
switch(config-ptp-clk)# clock-port dyn1
switch(config-ptp-port)# transport ipv4 multicast interface GigabitEthernet1/1
switch(config-ptp-port)# vlan 100
switch(config-ptp-port)# exit
switch(config-ptp-clk)# exit

On NX-OS the equivalent device-level command is ptp device-type boundary-clock, with per-interface participation controlled through clock-ports or ptp at interface level. Two rules prevent most operational surprises: assign every interface that should carry timing to the clock, and explicitly disable PTP on all the others. An unassigned interface sits in forward mode and exchanges PTP packets it should not, which shows up as an unstable clock rather than a clean error.

switch(config-ptp-port)# gmc-block     # refuse to accept a grandmaster on this port

gmc-block is how you stop a rogue or undesired grandmaster announcement from a customer-facing port from winning the BMCA.

Verification

switch# show ptp clock
switch# show ptp parent
switch# show ptp corrections
switch# show ptp port
switch# show ptp statistics

Read these in order: the clock must show a parent selected, the parent must be the grandmaster you intended, corrections must be small and stable, and per-port state must be master or slave as designed. Growing path delay or corrections that swing by microseconds indicate asymmetry - often a transport problem such as delay asymmetry in the optics or an unaccounted asymmetric link - rather than a configuration error.

Where PTP fails in practice

• Mixed profiles in one domain. Domain numbers must be consistent and distinct where profiles differ; overlapping domains cause two BMCA competitions.
• SyncE expectations. Combining PTP with physical-layer frequency (SyncE) improves holdover dramatically. Sites that expect G.8275.1 accuracy without SyncE are usually disappointed during network events.
• Oversubscribed paths. PTP is sensitive to queuing; timing traffic needs consistent forwarding treatment, which means a QoS policy that gives the timing class priority and does not let a burst delay timestamped packets.

Time distribution also depends on the servers consuming it: pair PTP with host-level NTP discipline as described in chrony NTP server configuration, and remember that monitoring data is only correlatable if timestamps agree - see Zabbix SNMP monitoring.

原文链接：https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/105x/config-guides/sys-mgmt/cisco-nexus-9000-series-nx-os-system-management-configuration-guide-release-105x/m-configuring-ptp-10x.html