Support for Multiple Master Nodes to Associate With a Single Slave Node in NetRef

Network node reference (NetRef) is an extension of the CTP adaptive port clocking. NetRef can be used to provide node level synchronization across a network. When NetRef is configured for primary or backup operation, the primary node sends clocking information to the backup node. The backup node uses an algorithm similar to that used for adaptive port clocking to control the local node clock so that it follows the clocking of the remote node. To operate in primary or backup mode, the remote primary node must be configured as a NetRef primary node with the IP address of the NetRef slave configured. The backup node must be configured as a NetRef backup node with the IP address of the NetRef primary node configured. You can configure up to four master modes, each of which can send their clocking information to a maximum of 10 slaves and the slave node can receive clocking information from the configured master nodes.

You can configure the four master nodes using CTP Menu or the CTPView web server during Netref slave configuration. As a result, a single slave node can use the IP address of up to four master nodes while you configure Netref slave node settings.

Each master node is assigned a priority during Netref slave configuration. The master node with the highest priority is assigned Priority 1, the second highest priority for the master node is Priority 2, and so on. You cannot configure the priority of the master nodes. The priorities assigned are unique for each masters while configuring Netref slave nodes. The slave nodes synchronize their local clock with the clock of the highest priority master node (Priority 1 master node). After the highest priority master goes down or when a problem occurs during the clock synchronization phase, the CTP device switches to its next highest priority master (Priority 2 master node). The slave nodes synchronize their clock with the clock of Priority 2 master node. The priorities of the master nodes are also switched in the backend, after switching of the master nodes takes place. In the case of flapping between the masters, the primary master (high priority) is retained or binding with the master that contains a good clock quality is maintained.

When switching of the masters takes place, an event of mastership change is logged into the syslog messages. The slave node synchronization query provides the details of the master node to which the slave is locked and the details of the configured master nodes along with their assigned priorities. You cannot configure the lowest priority masters until its higher priority masters are configured. Similarly, you cannot disable the highest priority masters until its lower priority masters are disabled.

When a node is configured as NetRef Master, it starts generating the NetRef packets and send them to the slave nodes. The slave node accepts the packets from the highest priority master node and the NetRef state of the slave node is changed to wait state. If 16 sequenced packets are received by the slave nodes, the NetRef state is changed from Wait state to Aggressive state. At this stage, if 8 packets are missed continuously, the NetRef state again moves back to the Wait state. These NetRef packets are processed and slope is calculated. Based on the slope, the clock of the slave node is in synchronization with the master node and the state changes to the Maintain state. The state changes from Maintain or Aggressive to Starvation when no NetRef packet is received in last 20 seconds. As soon as the node goes to Starvation state, switching of the master takes place. The packets are processed by the slave nodes to synchronize their clock with the next highest priority master node. Flapping of the masters occurs if you continuously “round robin” to each master and wait for 20 seconds for an incoming NetRef packet.

The LED becomes red when NetRef is in Wait or Aggressive state. The LED is green when NetRef is in Maintain state. The switching of the masters occurs as described in the following table:

If all the four master nodes goes down, the NetRef state remains in Starvation state and no switching will take place. When the NetRef state of the slave node is Maintain and the primary master goes down, the slave node is unable to receive the packets within the last 20 seconds. Therefore, the NetRef state of the slave node moves from Maintain state to Starvation state and switching takes place. When the NetRef state of the slave node is Aggressive and the primary master goes down, the slave node is unable to receive the packets within the last 20 seconds. Therefore, the NetRef state of the slave node transitions from Aggressive state to Starvation state and switching will take place.

When the NetRef state of the slave node is in Wait state (waiting for NetRef packets from the primary master node) and the primary master node is disabled but the secondary master nodes are sending NetRef packets to the slave node, switching will take place.

Revert option is not supported; when the primary node comes up, the slave node remains locked to the secondary master node and does not become locked to the primary master node.

Without multiple master nodes support, when a node is configured as slave, the node www_db string is

“23;1;0;0;0;0;0;0;0;0;0;5;1;5;1;5;1;5;1;5;1;;2|64|127.0.0.1/127.0.0.1/127.0.0.1/127.0.0.1/127.0.0.1/127.0.0.1/127.0.0.1/127.0.0.1/127.0.0.1/|0|255|;0;”

This www_db string is not different when multiple master nodes are configured for a backup node. The first IP address in the www_db string contains a priority of 1, the second contains a priority of 2, and so on, as shown as follows:

“23;1;0;0;0;0;0;0;0;0;0;5;1;5;1;5;1;5;1;5;1;;2|64|10.216.118.73/10.216.118.86/10.216.118.90/10.216.118.88/127.0.0.1/127.0.0.1/127.0.0.1/127.0.0.1/127.0.0.1/|0|255|;0;” When node is configured as master, the node www_db string will remain same as it is there in the earlier releases.