Target node alternate communication paths not retried when connected via Sterling Secure Proxy.

Hello Alex, Matt

From our call this week its understood that Alternate communication retry is getting failed only when SSP acts as intermediatory between CD Z (P & S Nodes) and alternate communication connection works perfectly when SSP is not in picture.

Can you please confirm again to avoid ambiguity ?

Thanks,

James

We are accepting the idea and considering it future releases. we can revisit this once we see the traction from other customers and partners (via Voting or Comments). Thank you for your patience and co-operation.

Thanks,

Product Management

@James Joseph

We have tested your suggestion on our lab systems. All requisite monitoring options were enabled, and we created condition where target SNODE was not reachable. SSP adapter did not go down, and upon submitting a process from PNODE we still got CSPA202E error and process went to hold queue.

We had a lengthy discussion with Lawrence Morland and Jeffry McGee on this, they should be familiar with the ask here.

Interesting suggestion, but in our setup, our adapters are not unique to an SNODE, so if a heartbeat to one remote SNODE were to fail, taking out that adapter would impact our ability to talk to many other clients. This could be an option but we'd need to drastically re-engineer, which is not a great option. We'd still like the ability to determine this on the CDZ side.

The following suggestion came from SSP team,

One suggestion is to use ‘failover’ feature in SSP. When failover is configured for the CD adapter in SSP, SSP monitors the SNode and if SSP could not connect to it , it will take the CD adapter down. This should make the PNode CD try the alternate node. This alternate node could be another SSP CD adapter which connects to another SNode.

Of course if the Snode goes down just when SSP CD adapter tries to connect for a regular cd session, this will not result in CD Pnode trying the alternate path. However subsequent connections will be able to fall back to alternate nodes.

FYI - failover can work in two modes: continuous mode – In this mode SSP monitors the SNode CD every 15 sec (configurable) and takes down the CD adapter if it fails to connect. not continuous mode – SSP starts monitoring only if the connection to the SNode CD fails as part of a regular CD session and stops monitoring once the Snode CD is up.

Here is the documentation https://www.ibm.com/docs/en/secure-proxy/6.1.0?topic=definitions-connectdirect-adapter-definition-properties

Thanks,

Product Management

Thank you for taking the time to share your ideas to IBM. We truly value our relationship with you and appreciate your efforts and willingness to share details about your experience, your recommendations, and ideas. We will soon review the same in the coming weeks and shall get back with a response.

Thanks,

Product Management

Specifically, when CD/Z is talking to a Secure Proxy host that is up, but the remote SNODE is down or unreachable, this is reported to CD/Z as a Secure Plus handshake timeout and no ALT.COMM paths are attempted. We would like to see this behavior changed, either by making the CSPA timeout message retriable, or by some other method.