configuration with single master multiple salves

[knb]

My topology has a vm on host A acting on a master which has n slaves on different vms on diffrent platforms yet on the same subnet

I am able to get the master to synch with only one slave at a time - when I try to add another slave the resp msg is not there listening via tcpdump on the master- I have 2 processes on the master, one started via /etc/init.d ptpd start

the other via the command line

running ubuntu 14.04

master config file setting -
PTPD_OPTS="-W -b eth0 -S -h -i 1 -u x.x.x.218 -L"

master command line
sudo ptpd -C -W -b eth0 -u x.x.x.218 -S -L -h

working slave
PTPD_OPTS="-g -b eth0 -i 1 -S -u x.x.x.153 -h"

failing slave
sudo ptpd -C -W -b eth0 -u x.x.x.151 -S -h

I would appreciate any guidance

[Jan Breuer]

Is there any reason to use unicast for you? There is multicast support to solve this. PTPd has limited unicast support. It is just 1:1 in this implementation and not 1:N.

It will also not work to run multiple ptpd on one machine on the same interface.

-u parameter tells ptpd address of the other machine, so you must tell master, who is slave and you must tell slave, who is master.

To solve your problem, you must use multiple PTPd master configuration on one machine but bind them to different network interfaces and different networks or switch to multicast.

Multiple unicast masters (expecting net mask 255.255.255.0, and x.x.0.218, x.x.1.218, x.x.2.218 are slave addresses)

sudo ptpd -C -W -b eth0 -u x.x.0.218 -S -L -h
sudo ptpd -C -W -b eth1 -u x.x.1.218 -S -L -h
sudo ptpd -C -W -b eth2 -u x.x.2.218 -S -L -h

[Jan Breuer]

Maybe in unicast mode, it will work on one interface. But I thing that you have problem with -u parameter.

[knb]

so what you are saying is that multiple unicasts won't work on the same subnet?

ie my
x.x.100.151
x.x.100.218
won't work?

I earlier tried
-W -b eth0 on the master and
-g -b eth0 on the slaves but

one of the slaves call it slave B loops thru refreshed 'IGMP multicast memberships' and 'now in state PTP_LISTENING'

the other slave B appears fine, the other resident on the same host as the master albeit a different vm

note there are switches along the path between the master and the slave which i believe have multicast issues I may not be be to change since they are campus switches - the IT folks say no rules are blocking multicast messages

still struggling....

[Jan Breuer]

I just say, that multiple unicasts won't work on the same interface with current PTPd. You can have as many unicast connections on the subnet as you want but no PC can be used twice.

PTPd is currently not designed to support multiple unicast slaves (as I remember it correctly) and it is not possible to run multiple PTPd listening on the same interface.

My experience with our campus network:
- IT folks also told me, that there should be no problem, but there was problem. They forget to configure something in one way, so it works from A to B but no message from B to A.
- I had also problem with IGMP version, because their switches support just one version (IGMPv2) while my PC was sending another one (IGMPv3) - so never correctly join multicast group.
- I had problems running PTPd in virtual machines and they disappear on real hardware.

My advice is:
Run wireshark/tcpdump on both machines, run both machines in -W mode and in multicast mode. Check if both ends generate IGMP join message and check if you can see some message from one machine on other one. If you can't see any message from other machine and it works on your real local network (not virtual), then just ask IT folks again with specific informations.

UDP ports: 319, 320
Multicast address: 224.0.1.129
Ask, what version of IGMP should you use v2 or v3 and what you are actualy using (see wireshark/tcpdump output)

[knb]

I think it might be the switches as you suggest based on the results of the following
3 scenarios

case 1 - both server and 2 clients are running concurrently
with -g/W -b -eth0 -S

both indicate join of 224.0.1.129 and igmpv3

the local slave vm x.151 is synching while the non co-resident vm x.207 is in the listen loop - all three run concurrently (run concurrently)

case 2 - server running

sudo ptpd -W -b eth0 -C -u 129.x.113.151 -h

local vm slave as
sudo ptpd -C -g -b eth0 -S -u 129.x.113.153 -h

no 3rd slave

I do get icmpv3

also get sync announce req and response - yeh

case 3 - server running

sudo ptpd -W -b eth0 -C -u 129.x.113.207 -h

non resident slave as
sudo ptpd -C -g -b eth0 -S -u 129.x.113.153 -h

no 3rd slave
I do get icmpv3
also get sync announce req and response - yeh

case 4

server and non co-resident slave

master as -W -b -eth0 -S
slave as -g -b -eth0 -S

it indicates join of 224.0.1.129 and igmpv3

but slave sees no ptp traffic

in the event the IT folks cant or wont change - I will ask them now

how could i make this work in unicast mode with multiple slaves ie. multiple unicast model?

your help has been great!

[Jan Breuer]

There is no support for unicast negotiation in current PTPd. Until somebody implements these signalling messages. There is no way to support multiple unicast slaves by one unicast master.

Concurrent linuxptp doesn't support unicast at all, so it is also not choice.

You can at least try to force IGMPv2 doing as root (replace eth0 by name of your interface)

echo "2" > /proc/sys/net/ipv4/conf/eth0/force_igmp_version

Start ptpd again and check tcpdump output if it generates IGMPv2 messages.

PS: It is IGMP not ICMP ;-)

[Jose Manuel]

Hi,

Anyone knows where i can define my .conf file to when ptpd2 starts init with my .conf?

I'm using buildroot,

Regards