Modify panning ID so nodes will join cluster

  • 3075104
  • 07-Feb-2008
  • 27-Apr-2012


Novell NetWare 6.5
Novell Cluster Services


Nodes will not join cluster
Modify panning ID so nodes will join cluster


There is an easy way and a hard way to fix this. The hard part mostly is gathering the data to verify it is a panning-ID issue, which is necessary for the hard method.

Fixing the Panning ID the EASY way:

The advantage of this is that it's quick and simple. The disadvantage is that the entire cluster needs to be taken down.

Unload clustering on every node of the cluster. Issue ULDNCS on each node of the cluster (including those who have not joined). When clustering is unloaded on every node, load clustering again.  All nodes should join successfully.

To verify there is a panning-ID problem (needed for the HARD method):

1. Find the panning ID of the cluster in DS. In iManager, Click on Cluster Options under Cluster. Select the cluster and click the Properties button. From there, choose the Protocols button. In the text box, there should be a line with the panning clusterid. Write down the decimal number.

2. Find the panning ID the cluster is actually using. Take a LAN trace for a few seconds, enough to capture a heartbeat packet from the cluster. By default, cluster heartbeat packets go out every second. Find a heartbeat packet in the trace that goes with this cluster. The panning ID (in Hex) will be 4 bytes, beginning at offset 26 (hex) of the packet, as shown in this graphic:

Convert the hex number to decimal. The workstation's OS probably has a calculator to do this easily. For windows, use calc. On Linux systems with KDE, kcalc will do this.

To see what the correct ID should be:

Convert the hex number to decimal...

1 Take the HEX number from the trace
2 In the above example, the cluster Panning ID is 5D77A681
3 Open calculator select HEX and Dword type the HEX Number 5D77A681
4 Convert this to Decimal (1568122497)
5 Subtract one from the resulting number getting (1568122496)

This is the correct Panning clusterid (1568122496) from the master node.

Fixing the Panning ID the HARD way:

The advantage of this is that the cluster will remain running. The disadvantage is that it is a bit more complicated.

Once verified that there is a panning ID issue, it can be fixed through Console One.

In ConsoleOne, do the following:
1. Right click on the cluster object and choose properties.
2. In the bottom left corner, click on Page Options.
3. Open the Protocol folder, highlight Cluster Protocol Internals, then click disable.
4. Exit back to the main Console One screen. Once again, open the properties of the cluster object.
5. In the Other tab, there should be NCS: GIPC Config. Expand this and modify the value that will show "#Cluster Protocols Parameters".
6. Find the part of the value with the "panning clusterid", and modify the decimal value following this to be the decimal number obtained from the packet trace earlier.
7. Under the Page Options, re-enable the Cluster Protocol Internals.
8. Unload cluster services on any node that will not join the cluster, then re-load clustering. They should now join without issue.

NOTE: Success has also been reported with the following steps:

1. Trace the traffic off of the servers.
2. Find the HEX number in a packet trace (This step lacks serious detail as to what to look for in the trace. The detail was not provided in the reports. It is only provided as another possibility for those looking for "other" ways to accomplish the same task)
3. Subtract the HEX number from FFFFFFFF (8 f's)
4. Convert the number to decimal
5. Add 2 to the number.

Additional Information

NOTE: The above procedure (FFFFFFFF - HEX + 2) has been shown to work for a Netware 6.0sp5 Cluster.

The panning ID the cluster is using has changed.
A cluster node will discard received packets if not transmitted by another node in the same cluster. A panning ID is constant for all nodes in the same cluster, and unique across different clusters. The panning ID allows multiple clusters to share the same LAN but remain isolated from each other, ignoring each other's packets.

Formerly known as TID# 10098550