Experiencing timeouts on our netconf requests

General
1

we have a netconf disconnection … ssh transport closed message seen in netconf.log. can you please suggest where could be the problem. there is a 15min delay before socket close error msg. which matches with ssh timeout.

3-Apr-2020::00:30:00.810 d01-dev105 confd[22407]: netconf id=653 new ssh session for user “icosuser” from 10.112.153.55
3-Apr-2020::00:30:00.835 d01-dev105 confd[22407]: netconf id=653 got rpc: {urn:ietf:params:xml:ns:netconf:base:1.0}get attrs: nc:message-id=“1”
3-Apr-2020::00:30:00.835 d01-dev105 confd[22407]: netconf id=653 get attrs: nc:message-id=“1”
3-Apr-2020::00:30:01.488 d01-dev105 confd[22407]: netconf id=653 sending rpc-reply, attrs: nc:message-id=“1”
3-Apr-2020::00:30:07.205 d01-dev105 confd[22407]: netconf id=653 got rpc: {urn:ietf:params:xml:ns:netconf:base:1.0}get attrs: nc:message-id=“2”
3-Apr-2020::00:30:07.205 d01-dev105 confd[22407]: netconf id=653 get attrs: nc:message-id=“2”
3-Apr-2020::00:30:07.812 d01-dev105 confd[22407]: netconf id=653 sending rpc-reply, attrs: nc:message-id=“2”
3-Apr-2020::00:30:09.798 d01-dev105 confd[22407]: netconf id=653 got rpc: {urn:ietf:params:xml:ns:netconf:base:1.0}get attrs: nc:message-id=“3”
3-Apr-2020::00:30:09.799 d01-dev105 confd[22407]: netconf id=653 get attrs: nc:message-id=“3”
3-Apr-2020::00:30:45.877 d01-dev105 confd[22407]: netconf id=653 sending rpc-reply, attrs: nc:message-id=“3”
.
.
3-Apr-2020::00:47:08.994 d01-dev105 confd[22407]: netconf id=653 ssh transport closed
3-Apr-2020::00:47:08.995 d01-dev105 confd[22407]: netconf id=653 failed to write to closed socket

2

The “15min delay before socket close error msg” is likely caused by a 15 minute timeout for TCP connections or unused sessions.

If ConfD had closed the connection due to an idle timeout (default is no timeout in confd.conf), it would have been logged as “closing due to idle timeout” in the ConfD NETCONF log.

Perhaps the network (e.g. a firewall, etc.) or the client closes the connection after 15 minutes of inactivity? If you do a tcpdump on the host where ConfD is running, you will likely see that the connection is not closed by ConfD.