Can't receive any new notifications from confd after do in-service upgrade

Because the NETCONF session for subscribing to the NETCONF notification stream is dedicated to notifications only, and hence does not have to be restarted after a capabilities change due to an in-service upgrade.

Ok, this make senses.

In my case, the client opened several netconf sessions before the in-service upgrade happen. Now what I plan to do is:
After in-service upgrade is completed, close all netconf sessions except the NETCONF session which subscribing to the NETCONF notification stream (so I will leave this NETCONF session open, no touch in this session after in-service upgrade).

Then I check the netconf request which close the netconf session, it will looks like:

<?xml version="1.0" encoding="UTF-8"?> 
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <close-session/> 
</rpc> 

In this request, there is no field to specify which session to close, then how does confd server to tell which session to close ?
Confd allows multiple netconf sessions opening simultaneously, correct ?

I need to take the above comment back and clarify after revisiting NETCONF over SSH RFC 6242. Closing the NETCONF session will close the SSH session.
https://tools.ietf.org/html/rfc6242#section-5

Exiting NETCONF is accomplished using the operation.
A NETCONF server will process NETCONF messages from the NETCONF
client in the order in which they are received. When the NETCONF
server processes a operation, the NETCONF server
SHALL respond and close the SSH session channel. The NETCONF server
MUST NOT process any NETCONF messages received after the
operation.

No, one NETCONF session per SSH session. A.k.a. “A NETCONF over SSH session”
https://tools.ietf.org/html/rfc6242#section-4

From the NETCONF event notifications RFC 5277:
https://tools.ietf.org/html/rfc5277#section-6

The :interleave capability indicates that the NETCONF peer supports
the ability to interleave other NETCONF operations within a
notification subscription. This means the NETCONF server MUST
receive, process, and respond to NETCONF requests on a session with
an active notification subscription. This capability helps
scalability by reducing the total number of NETCONF sessions required
by a given operator or management application.

So, again, if you don’t want to close the NETCONF over SSH session that is used for notifications after an in-service upgrade, don’t interleave other NETCONF operations on that NETCONF session. Dedicate it to NETCONF notifications.

Hm, you’re replying to (but not quoting) a post where you wrote:

However I can’t find the post where I said that - do you have a link? As it stands, it is clearly nonsensical, since (as you point out now) NETCONF sessions and SSH sessions are one-to-one - while you can have any number of NETCONF or SSH sessions in one SSH connection. And I actually tend to avoid talking about “SSH sessions”, since I think it is easily confused with “SSH connections”, and prefer to use “SSH channels” (every SSH session needs a channel - although not all channels are sessions…).

@per
This is the topic I mentioned before.

@cohult @per
One Netconf session to one ssh session. This fully makes sense.
The JNC package I am using, is implementing this logic:

Now my questions is:
For one ssh connection (or even lower level, one socket connection between confd client and confd server), does it allow multiple netconf sessions living simultaneously?
Or when I open a new netconf session, the previous opened netconf session must be closed before the new netconfd session open ?

Based on my understanding about how socket it works, it is feasible to support multiple session simultaneously but may not deserve to do that.

Now I am really confused by whether one socket connection supporting multiple netconf session.

I’ve read the JNC help text and it is very clear. Just read the help text for these methods in this order:




If you still don’t understand what is going on you can get an overview with links to the details here:


OK, but I don’t find any post in that thread either where I say that “you needed to reconnect the NETCONF sessions. Not the SSH session.”:slight_smile:

Yes.

It definitely works from the protocol point of view, but it may not make sense for a very simple client to make use of it.

@cohult
Thanks for the detailed guide.

I did read the comments of these JNC methods when I implemented the design to open/close the netconf session using this JNC device class.

Now what really confused me is I have updated my codes to close the netconf session except the netconf session used for notification. But I am surprised to find even I updated the logic as I mentioned above, the netconf session which subscribe to notification is still closed (I am 100% sure I am using the method device.closeSession(String sessionName), not device.close()).

I suspected there maybe something wrong in JNC methods, but I have take a glace of the inner implementation of closeSession, it seems make sense.

So this is why I asked the question previously:

Then I check the netconf request which close the netconf session, it will looks like:

<?xml version="1.0" encoding="UTF-8"?> 
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <close-session/> 
</rpc> 

In this request, there is no field to specify which session to close, then how does confd server to tell which session to close ?
Now let’s come back to this question, does the confd rely on the message-id to determine which netconf session to close if there are multiple netconf session living simultaneously?

@cohult @per
Please help me the above question. Thanks.

One NETCONF session per SSH channel.

If you still don’t understand what is going on you can get an overview with links to the details here:
https://en.wikipedia.org/wiki/Secure_Shell
https://en.wikipedia.org/wiki/NETCONF

The above two links doesn’t help the question I asked about the how the confd determine which netconf session to close if there are multiple netconf session.

In this netconf wikipedia page:

The only thing about close-session is:
<close-session> Request graceful termination of a NETCONF session

This doesn’t help.

As it says in the JNC code, one NETCONF session per SSH channel.

One NETCONF session per SSH channel.

Does one socket connection to confd service support multiple SSH channels simultaneously?
If it does, then I can open multiple ssh channels to the same confd server while each ssh channel carry one netconf session.

Using device.newSession() can open multiple sessions (each one corresponding to one ssh channel) to the same confd server.

I asked this in previous post in this topic, and I got the reply from @per. Please check this post.

I got the answer is Yes

If you look at the help text for the connect(), newSession(), closeSession(), and close() JNC methods that I pointed to earlier, what do you think?

Great, are we done now?

See https://tools.ietf.org/html/rfc6241#section-7.8 and https://tools.ietf.org/html/rfc6241#section-7.9 - i.e. <close-session> closes the session it is issued in (it is used in pretty much all the ConfD examples), <kill-session> closes the session identified by the <session-id> parameter.

Ok.
For the question:
Does one socket connection to confd service support multiple SSH channels simultaneously?
I got the answer.

For the question:
In this request, there is no field to specify which session to close, then how does confd server to tell which session to close ?

No, I don’t get the answer.

I think my question is clear enough but I don’t know why I can’t get the clear and straightforward answer for it.
For this question, I don’t really care one netconf session to one ssh channel.
We have confirmed multiple ssh channels to one confd server is supported. Then it means there will be multiple sessions to one confd server.
Then if I just want to close a specific session, how to tell confd thru netconf request ?

To answer this question, the first thing I need to know is supported or not supported. so as simple as YES or NO.
If it is YES, then the second step is How.

Ok, after I completed this post then I saw the latest reponse from @per.

Thanks for the reference. I think this is the answer I need. Let me check that and see what I should do.