I've been using ptpd to synchronize a set of Linux devices on a redundant LAN with good success. In particular, I used the Ethernet-bonding device (bond0) to handle the network redundancy at the device layer, and launched ptpd with "-b bond0", and all was well.
Now, however, we are forced (for unrelated reasons) to stop using bond0, and so the Linux devices' Ethernet ports now show up as separate eth0 and eth1. eth0 is the connection the primary network, and eth1 is the connection to the redundant backup network. In normal operation, both networks are passing data, or (if the user is too cheap to buy a second network switch) only the first network is connected.
My question is, is there any way to get ptpd to continue to synchronize clocks correctly as long as at least one of these two Ethernet devices is functional? The only thing I can think of would be to launch two instances of ptpd (one with -b eth0 and the other with -b eth1), but I suspect that even if that were possible they would probably fight with each other and yield a poor result.
Thanks,
Jeremy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a tough one, your suspicion is correct, if you launched two instances they would both start dragging the clock around. Once the clock is stable this might even work, but this is not something I would run in production.
With the existing ptpd 2.3.0 (this is the recommended version), I think you could make it work by writing a simple monitoring script to run every say 30 seconds and reconfigure ptpd to move to backup NIC if the primary NIC is down. You define a primary NIC and secondary NIC, you put the primary NIC say eth0 in the ptpd config file and run ptpd, the script checks which NIC ptpd is running on (/var/run/ptpd2.status), checks if link is up (ethtool), and if it's down, do a string replacement in the config file to configure it with the other interface and reload ptpd. Basically the script checks if the currently configured NIC is up, if it's not and the other NIC is down, it does nothing, but if the other NIC is up, it reconfigures ptpd to use that NIC.
Well you can do any variation a' la bonding with this idea, but you probably wouldn't want automatic flip back to primary, so you'd implement the behaviour of primary_reselect=2, to avoid multiple clock re-adjustments to two paths, especially if the primary starts flapping.
There is also netplug which monitors the NIC status more reactively than a periodic script - you'd write scripts to put into netplug.d to act on link up and down on the two NICs.
Introducing backup NIC as a feature in ptpd would actually be quite simple I think - I can consider this for the upcoming 2.3.1 version. Because APIs used to get a NIC's link state differ between OSes, this would have to be done not based on link status but on PTP port status (we go into LISTENING, timeout timer starts, when it expires we flip to the backup NIC and we keep moving back and forth until we're out of LISTENING). This is the only way we could implement this in ptpd without implementing full support for multiple port operation. Well, we could / should properly detect the link state and that would be great, but this increases the amount of effort needed to make this feature portable.
Last edit: Wojciech Owczarek 2014-05-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I've been using ptpd to synchronize a set of Linux devices on a redundant LAN with good success. In particular, I used the Ethernet-bonding device (bond0) to handle the network redundancy at the device layer, and launched ptpd with "-b bond0", and all was well.
Now, however, we are forced (for unrelated reasons) to stop using bond0, and so the Linux devices' Ethernet ports now show up as separate eth0 and eth1. eth0 is the connection the primary network, and eth1 is the connection to the redundant backup network. In normal operation, both networks are passing data, or (if the user is too cheap to buy a second network switch) only the first network is connected.
My question is, is there any way to get ptpd to continue to synchronize clocks correctly as long as at least one of these two Ethernet devices is functional? The only thing I can think of would be to launch two instances of ptpd (one with -b eth0 and the other with -b eth1), but I suspect that even if that were possible they would probably fight with each other and yield a poor result.
Thanks,
Jeremy
Jeremy,
This is a tough one, your suspicion is correct, if you launched two instances they would both start dragging the clock around. Once the clock is stable this might even work, but this is not something I would run in production.
With the existing ptpd 2.3.0 (this is the recommended version), I think you could make it work by writing a simple monitoring script to run every say 30 seconds and reconfigure ptpd to move to backup NIC if the primary NIC is down. You define a primary NIC and secondary NIC, you put the primary NIC say eth0 in the ptpd config file and run ptpd, the script checks which NIC ptpd is running on (/var/run/ptpd2.status), checks if link is up (ethtool), and if it's down, do a string replacement in the config file to configure it with the other interface and reload ptpd. Basically the script checks if the currently configured NIC is up, if it's not and the other NIC is down, it does nothing, but if the other NIC is up, it reconfigures ptpd to use that NIC.
Well you can do any variation a' la bonding with this idea, but you probably wouldn't want automatic flip back to primary, so you'd implement the behaviour of primary_reselect=2, to avoid multiple clock re-adjustments to two paths, especially if the primary starts flapping.
There is also netplug which monitors the NIC status more reactively than a periodic script - you'd write scripts to put into netplug.d to act on link up and down on the two NICs.
Introducing backup NIC as a feature in ptpd would actually be quite simple I think - I can consider this for the upcoming 2.3.1 version. Because APIs used to get a NIC's link state differ between OSes, this would have to be done not based on link status but on PTP port status (we go into LISTENING, timeout timer starts, when it expires we flip to the backup NIC and we keep moving back and forth until we're out of LISTENING). This is the only way we could implement this in ptpd without implementing full support for multiple port operation. Well, we could / should properly detect the link state and that would be great, but this increases the amount of effort needed to make this feature portable.
Last edit: Wojciech Owczarek 2014-05-08
Thanks Wojciech, that's helpful. If/when you add integrated backup NIC support, I'd be interested in trying it out.
-Jeremy