PTP820S 1+1 HSB CONFIGURATION not failing over

Hi Guys

I am pre-staging some PTP820S to be installed within the next month.  Everything has been going smoothly, besides the fact that the units don't seem to fail over.

I am using two PTP820S attached to a coupler,  these have a spliiter cable between the management ports for intra-unit communications.  They are also talking the switch via fibre, so I have a couple of fibre spliiter cables.

For all intensive purposes they appear fine.  Unit redundancy is configured and the standby is happy taking configuration updates from the active unit.  They both display the receive level from the other end.  

However, when it comes to testing the fail over, this is where things fall apart.  If I remove the power from teh active unit, the standby unit will not become the active unit and take over.  Also, trying to manually switch between the two units within the unit redundancy menu does not appear to work.

Something also unusual,  I have seen the units both be the "active" unit at some stage or other (not both active at one time, just both taken the role of active and the other standby), so it appears they do swap roles, however this seems to just 'happen' without any real reason/manual input.

I am running firmware version 8.7 on the 820s.

I have contacted Cambium support and they are just regurgitating sections of the user guide back at me and not really providing a whole lot of help.

If anyone has had issues like this and knows the fix, that would be fantstic.



Are there any alarms on the standby unit?

Can the standby unit "see" the active unit at the other end of the link? (I.e., what's the receive signal level that the standby is reporting?)

Did you do a copy to mate? (I.e., are you absolutely sure that both units have exactly the same configuration?)


Hi David

The standby unit is reporting a very similar RSSI as the active unit on the link ends.

No Alarms are present on either of the units.  An alarm is present if I don't 'Copy to Mate' as there is a configuration mis-match, but a quick copy to mate gets rid of that.



Do both units (active and standby) have the same hardware and software version?

Did you disable the fiber port "auto negotiation"?

Hi David

I have attached some screen grabs of the part numbers and firmware versions.

The speed has also been hard set, on the switch and on both physical sfp interfaces modules.  (I have also tried with auto-negotiate)



I am sorry you are still having problems!

Attached are the training slides we use in the PTP 820 Advanced Class.

See the last few slides--this shows you the preferred way to disable protection.

I suggest you disable protection, see that you are able to use all of the ODUs to create links.

(Create a link with PRI to PRI, mute them, then create a link with SEC to SEC. In other words, verify that all ODU hardware works properly (in a 1+0 link) without protection.)

Then carefully connect everything back together and enable protection in the order suggested by the attached slides.


HI David

Thanks for the assistance and the slide pack.

I will try your recommendations and let you know how I go.



Was there ever a resolution to this?  I'm experiencing the exact same problem.  The only difference is that I'm running 9.0 firmware.

Make sure that you turn off the auto-negotiation. this needed to be done on BOTH the radio ETH port and the Switch ETH port.

Hey Chris

There was no solution as yet.  Confguiring both ends to full duplex and speed did not alleviate any issues.  I had to close my support ticket with Cambium as we didn't have the units to continue testing and troubleshooting with.

However, I know have my hands on some spare units, and will re-open the support ticket to get this sorted.

I had also upgraded to 9.0 firmware and still had no luck.



I was able to resolve using v8.3 firmware.  It may be possible using 8.5.5 or 8.7 (I did not test), but I also had issues with 9.0 (although I have seen it work).

Really, so when you rolled back it just worked?  ugh

Thanks heaps for that mate, looks like I will be doing the same



I raised the exact same query about the same time. We were trying with and were eventually instructed by support to try 8.3. 

We had each radio ETH2 connected to a separate switch port of the same switch (no lag) so we can see which unit is active at the switch layer. Not sure if that is supported but seems to work OK.

Results of some simple verification tests was as follows:
1. A “manual switch” (Platform->Management->Unit Redundancy) now works immediately with loss of a 1-2 rapid pings. There are a few seconds of delay to get back into management of the new active unit. I have manual switched a few times and this has reliably failed over. 
2. If we pull out the active units ETH2 at the switch, failover is triggered and occurs immediately with loss of a 4-5 rapid pings.
3. If we reset the active in the gui, the standby takes over after ~10 seconds and we see a total loss of a ~6 seconds of traffic. I have reset the then active unit a few times and this has reliably failed over.
4. If we power off the active, the standby takes over. I tried this a few times OK.

The only issue remaining we have is this... if we boot up only 1 X HSB radio at each end, the link didn't work. We see the PTP820S at each end go into standby (prot led orange) and we cant access management.  Only way to see whats going on is to patch into the PROT cable interface and then browse to a backdoor IP When we  powered up a mate radio at one end, the link would recover. 

Thank you for your patience.

For your last issue, does the radio show any faults or complain about anything?

We will have a field service bulletin out on this shortly.

Thank you again for your patience.

We are sorry that people have been having issues with PTP 820S 1+1 HSB on 9.2!



Support has also referred me to firmware 8.3.  Which is a little upsetting as they have just rolled firmare out firmware 9.2.  And downgrading the PTP820s is not an easy process, as they need to be reconfigured.  And if they are already deployed up the mast and require a downgrade, then that makes the whole excersice a little more demanding as you don't easily have access to the direct to CPU connection.

To miss this for the last four firmware releases is a pretty big gap, and something that shouldn't have happened if correct testing and process was undertaken before release and shouldn't need to downgrade to a firmware released over a year and a half ago for a core capability of the radio.


We agree, and we apologize.

This is unacceptable.

9.5 will be out shortly--we'll be sure that it works before recommending that anyone upgrades!

Thanks for your patience!


I have it all configured on 8.3. I am able to perform the manual switch over via the GUI, I am also able to pull the carrier service from the active unit and the units perform a fail over, however, the units will not fail over when I pull the power from the ACTIVE unit, or if I reset the ACTIVE unit via the GUI.

I have attempted this with two different type of network switches, a CISCO and HP.  I have also performed testing with both the splitter cable, and an SFP in the switch for each ODU.  I get the same issue. when power is lost to the active unit, no failover occurs.

I have all NIC's set to non-negotiate.

Is anyone able to shed anymore light on this?

As this issues has now taken a good three to four months and lots of wasted man  hoours to get to a semi result.  These units will be travelling to site for installation at the end of this week, with or without HSB working at 100%.


I have the same issue. Does anybody found a way to have 1+1 HSB working fine?



Hey Leandro

I managed to get it all installed and working with all the failovers working correctly when up the tower during the SAT using firmware version 8.3

Firmware version 9.7 is out and is meant to solve the bug/issue that was found in the versions 8.5 through 9.2

Hope that helps