linuxptp-users

[Linuxptp-users] I am trying to get PTP to work over an interesting network topology.

[Robb <rba...@gm...>]

I am having trouble getting PTP to work over a network bridge br0.

They are both CentOS 6.5 machines with 2.6.32-504.8.1.el6.x86_64, and running
linuxptp-1.3-1.el6.x86_64.

Each machine has two NICS.
eth0 [e1000e] Intel I217-LM (rev 05)
eth1 [igb]    Intel I210 (rev 03)


Here is the topology:

Machine1:
br0  192.168.2.1
  -bridges both wlan0 and eth1
  -has a dhcp server running on it.
eth0 192.168.1.17
  -gets it's ip from LAN
eth1
  -connected to eth0 on machine 2
wlan0
  -provides a Wifi Access point to the 192.168.2.* network

Machine2:
eth0 192.168.2.7
  -connected directly to eth1 on Machine1
  -gets its IP from Machine1's dhcp server
eth1 down


What I would like to do is do the following:
[Machine1 ~]# ptp4l -i eth1 -m
[Machine2 ~]# ptp4l -i eth0 -m

I changed the default route on Machine1 and can visually see in iptraf-ng that
the ptp packets are going to 192.168.2.*  and while the machine happily detects
master and slave at first, nothing else happens, the Machine2 assumes grand
master role..

[Machine1 ~]# ptp4l -i eth1 -m
ptp4l[2847.269]: selected /dev/ptp1 as PTP clock
ptp4l[2847.271]: driver changed our HWTSTAMP options
ptp4l[2847.271]: tx_type   1 not 1
ptp4l[2847.271]: rx_filter 1 not 12
ptp4l[2847.271]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[2847.271]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[2853.271]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[2853.271]: selected best master clock d05099.fffe.09aaf4
ptp4l[2853.271]: assuming the grand master role

[Machine2 ~]# ptp4l -i eth0 -m
ptp4l[966.068]: selected /dev/ptp0 as PTP clock
ptp4l[966.075]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[966.075]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[967.756]: port 1: new foreign master d05099.fffe.09aaf4-1
ptp4l[971.756]: selected best master clock d05099.fffe.09aaf4
ptp4l[971.757]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1191.765]: port 1: UNCALIBRATED to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1191.765]: selected best master clock d05099.fffe.5df7e6
ptp4l[1191.765]: assuming the grand master role


iptables is down on both machines.
Works fine (as expected) with NO bridge when Machine1:eth1 192.168.2.1 (master)
and Machine2:eth0 192.168.2.7 (slave).

So what is the bridge messing up? And is there a way to fix it?

I would appreciate any insight I can get.  Even if it is a suggestion for a
better topology.

Thanks,

Robb

Re: [Linuxptp-users] I am trying to get PTP to work over an interesting network topology.

[Richard C. <ric...@gm...>]

On Tue, May 26, 2015 at 03:29:01PM -0500, Robb wrote:
> I am having trouble getting PTP to work over a network bridge br0.

I have not tried PTP over a Linux SW bridge, and I am not sure if the
kernel stack will play along.  In my experience, Linux SW bridging is
a bit flakey.

(PTP *does* work over tun/tap, but only after I patched the kernel.)
 
> So what is the bridge messing up? And is there a way to fix it?

The default transport is multicast UDP.  Maybe the SW bridge is
dropping multicast.  Run wireshark on the end points to see if the PTP
messages are getting through.

> I would appreciate any insight I can get.  Even if it is a suggestion for a
> better topology.

One easy thing to try is Layer2 transport:

   ptp4l -i eth0 -m -q -2

This doesn't require the stack to join the multicast group, and so
maybe it will "just work."

HTH,
Richard

Re: [Linuxptp-users] I am trying to get PTP to work over an interesting network topology.

[Robb <rba...@gm...>]

I attempted to enable UDP multicast by setting
net.ipv4.all.rp_filter = 0
in /etc/sysctrl.conf with no luck

However, I used your suggestion to use layer 2 and it did "just work"
which is really nice.  It is also really refreshing to see a mailing list
responded to so quickly, and with such accurate and helpful information.

Thank you very much.

-Robb





On Tue, May 26, 2015 at 3:53 PM, Richard Cochran
<ric...@gm...> wrote:
> On Tue, May 26, 2015 at 03:29:01PM -0500, Robb wrote:
>> I am having trouble getting PTP to work over a network bridge br0.
>
> I have not tried PTP over a Linux SW bridge, and I am not sure if the
> kernel stack will play along.  In my experience, Linux SW bridging is
> a bit flakey.
>
> (PTP *does* work over tun/tap, but only after I patched the kernel.)
>
>> So what is the bridge messing up? And is there a way to fix it?
>
> The default transport is multicast UDP.  Maybe the SW bridge is
> dropping multicast.  Run wireshark on the end points to see if the PTP
> messages are getting through.
>
>> I would appreciate any insight I can get.  Even if it is a suggestion for a
>> better topology.
>
> One easy thing to try is Layer2 transport:
>
>    ptp4l -i eth0 -m -q -2
>
> This doesn't require the stack to join the multicast group, and so
> maybe it will "just work."
>
> HTH,
> Richard