TLS call-home : Client session establishments with redundant <get-schema>

[Bharanidharan-S]

Dear Team,

We use TLS call-home feature with "netopeer2-server 1.1.77". Could see get-schema involvement during each client session establishments, even with the usage of nc_client_set_schema_searchpath("/usr/local/yang/"). Please note, all netopeer2-servers are loaded with the same yang files & in other separate machine, all netopeer clients are running or trying to establish more connections with different servers. Its acceptable, if get-schema involved during first client establishment. But it is invoked in all other client session establishments too, when the same yang files are already stored in /usr/local/yang during the first client establishment. Due to which, its causing delay between successive session establishments. Ideally we expect the successive connections must happen without much delay.

Can someone please let me know why get-schema involved in all session establishments.

For more clarity, provided connection details below:

Thanks in advance..

[Bharanidharan-S]

Why get-schema, even if we use nc_client_set_schema_searchpath("/usr/local/yang/")? We use different client server versions - does it bother?

• netopeer2-cli 2.0.64
• netopeer2-server 1.1.77

[michalvasko]

Yes, I think this was improved fairly recently so if you are still using netopeer2 v1, then it is certainly not fixed in the libnetconf2 you have installed with it. If you use the current versions, the local modules should be used when possible.

[Bharanidharan-S]

Yes, I think this was improved fairly recently so if you are still using netopeer2 v1, then it is certainly not fixed in the libnetconf2 you have installed with it. If you use the current versions, the local modules should be used when possible.

@michalvasko Thanks for the response. Are you taking about the improvements happened on netopeer-server side? My point here is, netopeer-cli shouldn't invoke get-schema as it's still with version "2.0.64".

[michalvasko]

No, technically the improvements are on the client side, specifically in libnetconf2. But you will have to update all the dependencies (such as whole netopeer2 with both the server and client) to use it.

[Bharanidharan-S]

Okay. In general get-schema is being requested from client side. So i think its not necessary to focus on netopeer server version.

While we use nc_client_set_schema_searchpath("/usr/local/yang/") in netopeer2-cli v1, it wasn't requested for get-schema. But in netopeer2-cli v2 (upgraded its dependencies too), the get-schema is being requested, even with nc_client_set_schema_searchpath(). Can you please provide clarity on this.

[michalvasko]

There are a number of factors deciding how to retrieve each schema. It should be loaded from a file if a specific module revision is required and that module is present in the search path. If you think some modules are loaded using get-schema despite this, run verb verbose in the CLI before connecting and then paste all the output of the connect command (ideally with the latest devel version of libnetconf2).

[Bharanidharan-S]

@michalvasko There are 2 queries.

1. I could see few yang files are requested via get-schema, even though all the yang files are same in client & server. I don't understand why..! Client session logs attached here [client_session.txt]

2. While trying to establish connection for the next incoming callhome request, its taking nearly 7 to 10 seconds for any number of trials. This is weird one which we see here with below simple code. Can you please let us know how to avoid such delays for the next callhome connection establishment.

struct nc_session *session;

nc_client_init();

/Load Yang Schema Search Path/ nc_client_set_schema_searchpath("/usr/local/ruyang/");

string sCaCertAbsPath = CA_CERT_PATH + string(CA_CERT_FILE_NAME);

/* Set CA certificate */ nc_client_tls_ch_set_trusted_ca_paths(sCaCertAbsPath.c_str(), NULL);

string sClientCertAbsPath = CLIENT_KEY_PATH + string(CLIENT_CERT_FILE_NAME); string sClientKeyAbsPath = CLIENT_KEY_PATH + string(CLIENT_PRIVATE_KEY_FILE_NAME);

nc_client_tls_ch_set_cert_key_paths(sClientCertAbsPath.c_str(), sClientKeyAbsPath.c_str());

nc_client_tls_ch_set_crl_paths(NULL, CLIENT_CRL_PATH);

char *host = NULL; if (!host) { host = "::0"; }

unsigned short port = 0; if (!port) { port = NC_PORT_CH_TLS; }

nc_client_tls_ch_add_bind_listen(host, port);

while(1) { ret = nc_accept_callhome(60 * 1000, NULL, &session); }

[michalvasko]

The log seems fine, only the YANG modules without a specific revision are requested from the server, to make sure they are the latest ones. When establishing a new connection, the YANG context is built, which can take quite a lot of time in case you are using lots of and/or complicated YANG modules.