PTP670 and NIDU Port Flapping

I have a PTP670 in 4.9 GHZ running on a conservative link. All wireless errors are Zero, the link margin is perfect, units are backed upon UPS, no errors, no physical layer issues on the wireless link.

Our configuration is as follows:




System software is  50670-02-60. I know this does not support TDM operation, however the client did not wish to configure the TDM support at the time of installation and I know that is a downgrade that requires a prior software revision.

The issue that is happening is at various times we see FCS errors (CRC) accumulate on the Cisco switch port that faces the NIDU. Then, at variuos times (>12 hour intervals), the port facing the NIDU will go down, come up, and repeat (flapping) until it clears on its own, or if detected during the event, the Cisco port is shutdown/brought back up. I have tried hard coding the 1000/full on the switch as well, offering different speed/duplex configurations. I could not get the NIDU to pass traffic at anything other than a 1000/Full setting on the switch. (Hard coding 100F did not work)

I have 100F and 1000F set as available on the PTP670 radios.

Data port wireless down alert is disabled.

Is it possible that the NIDU is rebooting? 

Is it not advised to have the NIDU in use (for ethernet traffic) if using non-support firmware for TDM?

I cannot find any other explnation for this but would like to have a definitive answer. The PTP670 does not indicate that the NIDU is present, and the NIDU status led is RED,showing no communications with the PTP670.

I'm quickly concluding that the NIDU should not be in-network if the software on the PTP670 does not support it. ( I have TDM keys as well , but not installed )


Kindest Regards,


I have just now eliminated the NIDU in the configuration (CISCO SWITCH to PSU/PTP670) in hopes of finding the root cause of this issue. 


Hi Bob,

Thanks for your report. I don't know what happens if the NIDU is connected when the ODU is running 670-02-60. I think that's a possibility we didn't consider. It seems from your experience that something useful happens. I agree that it's a good idea to remove the NIDU as you have done. I hope this fixes your problem, but I'm not 100% convinced it will. Please get back to us to tell us how you get on.


Thank you.

To be noted-I removed the NIDU on one end of the link (MASTER), the slave side still has the NIDU in line and is accumulating FCS errors (2 total)  with 0 on the Master end since clearing the counters 2 hours ago.

These are Cisco SG350-10 managed switches.  I'm on the copper side of a combo SFP port right step would be to remove the slave end NIDU and then move to copper-only switch ports.

*trying* to follow good practice to allow auto-negotiation but offering 1000 Full to the port.