Bruce Simpson, Ph.D.PSA for people doing network #protocol development in 2026: If you bridge your laptop's #Ethernet port for #KVM guests to run in bridge mode, you can't use hardware timestamping directly for time synchronization, unless you run #IEEE #1588 in Annex F (Ethernet) mode. This applies to #chrony, #ptp4l and #ptpd equally. None of them know anything about bridged operation.
This does not prevent guest VMs from syncing to #PTP, but you won't get the benefits of hardware #timestamping you may as well rely on your #hypervisors native mechanisms, unless you need to measure pDelayResp latency and jitter on the virtual switch itself (in this case, #Linux bridge).
My only real indication of this was the lack of #linuxptp #ptp4l summary logging in #systemd's journalctl -f output, coupled with all the announce and delay timeouts at logging_level > 6; the #ThinkPad was NOT syncing AT ALL.
And it could not, by design, unless these #daemons can be persuaded to
"borrow" the bridge's assigned #IPv4 address on the physical #Ethernet port.
And it could not, by design, unless these #daemons can be persuaded to
"borrow" the bridge's assigned #IPv4 address on the physical #Ethernet port.
In theory this should be fine, modulo #IPv4 #StrongES restrictions; #FreeBSD
introduced a further out-of-box hardening of this which may affect such
"unnumbered" interfaces; although, like legacy #Cisco IOS platforms, the
address of the bridge should be "reachable" from all other physical links
on the IPv4 node. I smell a patch for someone!
introduced a further out-of-box hardening of this which may affect such
"unnumbered" interfaces; although, like legacy #Cisco IOS platforms, the
address of the bridge should be "reachable" from all other physical links
on the IPv4 node. I smell a patch for someone!
On the other hand, when #ptpd is bound to an #Ethernet bridge member in #Linux where an IPv4 address is not assigned, it refuses to run and complains.
#ptpd can't therefore use hardware #timestamping on a Linux bridge member,
as it knows nothing about bridges, and must be manually configured for
software timestamping on the bridge itself as a fallback. Moreover, ptpd2
lacks logging for which #SO_TIMESTAMPING or #SO_BINTIME mode it is using.
#ptpd can't therefore use hardware #timestamping on a Linux bridge member,
as it knows nothing about bridges, and must be manually configured for
software timestamping on the bridge itself as a fallback. Moreover, ptpd2
lacks logging for which #SO_TIMESTAMPING or #SO_BINTIME mode it is using.
P.S. To make matters more confusing, the summary_interval in #linuxptp ptp4l.conf is a log2 value, not a linear interval in units of seconds.
And the name of that #StrongES extension? net.inet.ip.source_address_validation, which, incidentally, is missing from the #FreeBSD ip(4) man page just now, along with its close cousin, net.inet.ip.rfc1122_strong_es. See #IETF #RFC1122 https://datatracker.ietf.org/doc/html/rfc1122
Volunteers?
Volunteers?