A bureau upgraded OSN1500 devices using ToolkitR4 analog package load, the version was upgraded from V1R8C02B01L (5.xx.18.50) to V1R8C02SPC200 (5.xx.18.50P01). The upgrade process did not report any errors, but after activation, I found that the alternate master version was still the original version number. Switching to DC tool upgrade, the phenomenon is still the same.

None

1, the scene will be upgraded successfully the main main control pulled out, and then loaded with the simulation package upgrade unsuccessful original standby main control can be upgraded normally.
2, check found that the network element of the two main control board hardware type is not consistent, respectively, N3GSCC and N3GSCC-B2. confirmed, due to the previous version of Toolkit and DC in the simulation package upgrade master, the implementation of the way is to load the software to the main master, and then synchronized by the main master to the standby master. At this time, due to the hardware inconsistency between the primary and backup masters, the software could not be synchronized, resulting in the upgrade failure of the backup master. When upgrading the crossover board, the problem of unsuccessful upgrading will not occur because the realization is different from that of the master control.
3. The latest version of DC tool (DC V2R7C02SPC008) has changed the upgrade implementation method of analog package loading, so that the standby master can be upgraded in the above cases.

Due to the implementation of the upgrade tool, it is not possible to upgrade the standby master board if the hardware types of the master and standby masters are not the same.

In this case, the hardware type inconsistency between the master and backup masters only means that the non-B2 single board and the B2 single board are the masters of each other. Other scenarios such as N1GSCC and N3GSCC are only present for a short period of time during the master replacement process and are not allowed to run for a long period of time.