PCS 7 V9.0 +SP3 running on Windows Server 2016

1x ES, 2x redundant AS pairs (CPU 410-5H), 2x redundant OS server pairs, 1x MS

About a month ago we had a communication problem in one AS, and part of the troubleshooting process was to delete all system-generated CFCs and generate module drivers again.  Ever since that download, the OS has been showing these error messages every 5-30 seconds (it says the source is the H-system's CONEC block):

"Redundancy loss connection ID: 16#1" 

"Redundancy loss connection ID: 16#3"

A few weeks later we had a different communication problem on the other H-system (AS2), and we performed the same troubleshooting step (deleting/regenerating all system-generated CFCs).  However we did not compile/download any changes to the associated OS at that time, and we never saw any of those error messages in the OS.  Today we performed a full OS download (the first one since remaking the system-generated CFCs), and we are getting very similar error messages from the CONEC block for that H-system (also every 5-30 seconds):

"Redundancy loss connection ID: 16#3"

"Redundancy loss connection ID: 16#4"

Other than these messages we have no reason to believe there is an actual problem with either AS.  There are no other symptoms, and these symptoms only appeared after making a software change (remaking the system-generated CFCs).

I would like to try enabling the DIAG_BUF setting in the CONEC block itself (in hopes the HW diagnostic buffer will provide more info about the cause of the error), but I'm worried this could have unintended consequences.  I've also considered disabling the OS message but I don't want to do that until I'm certain these are false alarms and can be ignored.  Has anyone seen this behavior before or know what should/shouldn't be attempted in the troubleshooting process?

I think its likely you could have a real issue even if you don't *see* it.

Which AS or OS is associated with those network connections?
Did you download NetPro after you did all of that @ chart reorg and regeneration? (connections and gateways is sufficient for AS, complete on OS when runtime shut down on each OS)

When you do that you end up effecting the IK Alarms chart which is coordinating AS wide interconnections.  Are you really sure your AS<>AS data has been good since you started making changes?

 HI there,

I am also facing the same issue... unable to trace why this is coming.. Didi you receive the resolution ?

jwr1701

PCS 7 V9.0 +SP3 running on Windows Server 2016

1x ES, 2x redundant AS pairs (CPU 410-5H), 2x redundant OS server pairs, 1x MS

About a month ago we had a communication problem in one AS, and part of the troubleshooting process was to delete all system-generated CFCs and generate module drivers again.  Ever since that download, the OS has been showing these error messages every 5-30 seconds (it says the source is the H-system's CONEC block):

"Redundancy loss connection ID: 16#1" 

"Redundancy loss connection ID: 16#3"

A few weeks later we had a different communication problem on the other H-system (AS2), and we performed the same troubleshooting step (deleting/regenerating all system-generated CFCs).  However we did not compile/download any changes to the associated OS at that time, and we never saw any of those error messages in the OS.  Today we performed a full OS download (the first one since remaking the system-generated CFCs), and we are getting very similar error messages from the CONEC block for that H-system (also every 5-30 seconds):

"Redundancy loss connection ID: 16#3"

"Redundancy loss connection ID: 16#4"

Other than these messages we have no reason to believe there is an actual problem with either AS.  There are no other symptoms, and these symptoms only appeared after making a software change (remaking the system-generated CFCs).

I would like to try enabling the DIAG_BUF setting in the CONEC block itself (in hopes the HW diagnostic buffer will provide more info about the cause of the error), but I'm worried this could have unintended consequences.  I've also considered disabling the OS message but I don't want to do that until I'm certain these are false alarms and can be ignored.  Has anyone seen this behavior before or know what should/shouldn't be attempted in the troubleshooting process?

I am also facing the same issue... 

I was experiencing the same problem at our site.

 Narrowed down to X308-2M switch on secondary PlantBus loop. 

The switch did not indicate any fault, but I was unable to login into the management UI. 

Using Proneta network analysis I observed the switch would sometimes be there, then moments later the switch was gone from the Topology view. 

A Simple reboot of the switch solved the issue. Will most likely replace it soon.

Hope this helps some one else.

PJ