Multiple Interfaces on Same Subnet Breaks PTP: A Tech Support Guide

When multiple network interfaces reside on the same subnet, Precision Time Protocol (PTP) synchronization fails because the operating system cannot deterministically select which interface should handle PTP messages. This ambiguity leads to packet loss, jitter, and complete time source failure. The solution involves configuring specific routing rules or binding PTP daemons to a single physical interface.

The Root Cause of Interface Ambiguity

In a standard network configuration, each host is assigned a unique IP address per subnet. However, when a server or industrial device has two or more network cards connected to the same logical subnet, the kernel faces a conflict. Both interfaces appear valid for reaching the same destination. When an application like ptp4l (part of the linuxptp suite) attempts to send or receive PTP frames, it must choose an outgoing interface. Without explicit guidance, the operating system may load-balance, round-robin, or arbitrarily pick one interface based on internal metrics that change over time.

This selection process is catastrophic for PTP. PTP relies on precise timestamping at the hardware level. If packets are sent out of interface A but timestamps are recorded as if they were sent from interface B, the delay calculation becomes invalid. Furthermore, if the peer device only listens on one interface, packets sent via the other are silently dropped. The result is a "flapping" clock that jumps between different time sources or loses synchronization entirely.

Detecting the Problem in Your Logs

Before applying fixes, you must confirm that interface ambiguity is the culprit. Check your system logs for patterns indicating mixed traffic. Look for messages from ptp4l or phc2sys showing frequent state changes or unexpected delays.

• State Flapping: Messages such as state: UNCALIBRATED to SYNCHRONIZATION followed immediately by SYNCHRONIZATION to FAULTY suggest inconsistent message reception.
• Port Delay Variance: If the calculated port delay varies wildly between updates, it often means packets are arriving via different paths with different latencies.
• Multicast Mismatch: PTP uses multicast addresses (typically 224.0.1.129 for IPv4). If you see high packet counts on one interface but low on another, the OS is splitting the traffic.

You can verify this by running tcpdump -i any ether proto 0x88f7 to filter for PTP EtherType traffic. Observe which interfaces are receiving and transmitting these frames. If you see transmission on both interfaces simultaneously, you have confirmed the ambiguity issue.

Solution 1: Binding PTP4L to a Specific Interface

The most direct fix is to force the PTP daemon to use only one physical interface. This eliminates the guessing game for the kernel. In the linuxptp suite, this is achieved using the -i flag.

ptp4l -i eth0 -m

Here, -i eth0 tells the daemon to bind exclusively to the eth0 interface. The -m flag enables syslog logging for easier debugging. By restricting the socket to a single interface, all PTP management messages and data packets are guaranteed to traverse the same path, ensuring consistent timestamping.

If you are using systemd to manage the service, you should edit the unit file to include this parameter. Create a drop-in override or modify the ExecStart line in /etc/systemd/system/ptp4l.service.d/override.conf. After modifying the service file, reload the daemon with systemctl daemon-reload and restart ptp4l.

Solution 2: Using Network Namespace Isolation

For complex environments where you cannot simply disable an interface, isolating PTP traffic into its own network namespace provides robust separation. This method creates a virtual network stack that sees only the desired interface.

1. Create a new namespace: ip netns add ptp_ns.
2. Move the target interface into this namespace: ip link set eth0 netns ptp_ns.
3. Bring up the interface within the namespace: ip netns exec ptp_ns ip link set eth0 up.
4. Run ptp4l inside the namespace: ip netns exec ptp_ns ptp4l -i eth0.

This approach ensures that no other processes on the main system can interfere with PTP traffic, and the kernel's routing table within the namespace contains only the necessary routes for the PTP master.

Solution 3: Static Routing and Policy Rules

If binding the daemon is not feasible due to legacy software constraints, you can influence the kernel's routing decisions. Use policy-based routing to ensure that packets originating from the PTP process are always routed through the correct interface.

Create a custom routing table (e.g., table 100) and add a default route via the correct gateway or direct link. Then, add a rule that matches the source IP of the PTP interface to use this table. This prevents the kernel from choosing the wrong interface for outbound PTP packets. Note that this does not solve inbound packet filtering, so combining this with daemon binding is recommended.

For further details on managing static IPs in complex multi-homed setups, refer to our guide on Connecting to a device with a static IP. While focused on IP assignment, the principles of interface selection apply similarly.

Verifying the Fix

After applying any of these solutions, monitor the PTP status closely. Run ptp4l -s to check the current state. It should remain stable in FAULTY (if no master is present) or SLAVE/MASTER states without rapid transitions. Check the current_master_offset value; it should stabilize to a small nanosecond range rather than fluctuating wildly. Consistent offset values indicate that the interface ambiguity has been resolved.

Frequently Asked Questions

Can I use bridge interfaces to solve this problem?

No, bridging multiple interfaces on the same subnet will exacerbate the issue. Bridges operate at Layer 2 and forward frames based on MAC addresses, which does not resolve the Layer 3 routing ambiguity for PTP. You must isolate or bind at the interface or namespace level.

Does disabling one interface completely fix the issue?

Yes, if you disable the unused interface via ip link set eth1 down, the kernel can no longer route PTP traffic through it. However, this reduces redundancy. If the active interface fails, you lose connectivity. Binding the daemon is preferred for maintaining availability while ensuring deterministic behavior.

What happens if I don't fix this issue?

Without a fix, your system will experience intermittent time synchronization errors. Applications relying on precise timing, such as financial trading systems or industrial control loops, may fail or produce incorrect results. In severe cases, the clock may drift significantly, causing audit log discrepancies.

Is this issue specific to Linux?

While the examples use Linux tools, the underlying networking principle applies to all operating systems. Windows and macOS also struggle with multi-homed hosts on the same subnet unless specific API calls or registry settings are used to pin traffic to a single adapter.

How do I troubleshoot if binding doesn't work?

If binding fails, check for firewall rules blocking PTP multicast. Ensure that the interface is not part of a bond or team that handles traffic differently. Also, verify that the NIC firmware supports hardware timestamping, as software timestamping may still show inconsistencies even with correct interface selection.