We have CC on premise and CPI on the SCP. CC closes the channel(s) often, unpredictably, inconsistently. Our Network engineer enabled the trace between SCP and CC and concluded that SCP is the one asks CC to close a channel.
Here is our Network Engineer explanation.
Did other face similar problem and what did you do to fix it?
------------------------------------------------
Network Engineer Trace details.
--------------------------------------------
The "Encrypted Alert" that I see in the capture means Wireshark can't decrypt it. The reason why this packet appears is usually a "close_notify". This is normal and is used by the TLS protocol for notifying the peer that the connection can be closed. This is usually sent when there is no more traffic to send by the originator of the packet and the connection termination follows.
Protocols like HTTP support a one-sided shutdown, for example, the client sends the request data followed by a FIN to notify the server, that it will not send any more data. But it will still receive the data send by the server. The server will acknowledge the FIN. Once the server is done it will send its own FIN which the client ACKs. This is a graceful TCP connection termination.
A normal graceful TCP closing connection should be using packets FIN->(FIN,ACK)->ACK. In our case as shown in the capture the SAP cloud start the closing of the connection. the FIN is in the "Encrypted Alert" and it just says that the side sending the FIN will not send any more data. The receiver sends the FIN Ack with one more sequence number received in the FIN. At this stage the connection is closed in one direction. Normally at this state the application is informed about the close of connection. For other direction, a new FIN is sent with a sequence number. The receiving side sends the (FIN,ACK) and connection is closed in both the directions.
In my conclusion, bot side are doing closing their side of the connection and the capture show the SAP cloud is the one that initiates the termination of the connection. Furthermore, we know that there are on average there are at least three simultaneous connection going between server and cloud at the same time and while the connection is question is been close the other connection are remain active and moving traffic. The capture does not show any period of time when all the connection are close indication some kind of connection problem or unreachability.