hi,
I have issue confirmed-commit operation with time-out as 100sec. and persist-id as 11111.
Now, when i close this session, i see that commit is permanent. Is this expected??
Or it should revert to original config after 100sec ??
hi,
I have issue confirmed-commit operation with time-out as 100sec. and persist-id as 11111.
Now, when i close this session, i see that commit is permanent. Is this expected??
Or it should revert to original config after 100sec ??
Hello.
Do you see scenario that commit is not reverted after timeout period?
There is an example distributed with ConfD called netconf_confirmed_commit.
Please, can you try it in your environment (see README)? The example does not set timeout, so it
uses default timeout (600s).
It works fine. Meaning, configuration gets reverted after 600 sec(default) or any other specified time.
Can someone please answer my above question?
Hi Michal,
I want to explain Hatim’s problem.
If he does confirmed-commit without setting persist-id it work just fine.
If he configure persist-id and keep the session open it work fine, after timeout expired there is rollback.
Only when configuring persist-id and closing the session, the rollback won’t be executed after timeout expired.
please assist.
Thanks,
Evyatar
Hello,
thanks for detailed description. The example I have referred to (netconf_confirmed_commit) performs commit with <persist> and confirms it with <persist-id>. According to the description, it seems to me you didn’t send confirmation message within the timeout. Please can you check. The scenario should be:
1 . session
configure (<edit-config>)
commit (<commit> with <confirmed/> and <persist>)
<close session>
2 . session
commit (<commit with <persist-id> corresponding to the <persist> from ` 1 . session) - to make config persistent and not to rollback
For reference, I’m pasting messages from the example ( <edit-config> values are related to the example)
1 .session
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>
]]>]]>
<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<edit-config>
<target>
<candidate/>
</target>
<config>
<hosts xmlns="http://tail-f.com/ns/example/host"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<host nc:operation="merge">
<name>thost</name>
<ip>192.168.1.33</ip>
</host>
</hosts>
</config>
</edit-config>
</rpc>
]]>]]>
<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<commit>
<confirmed/>
<persist>test_commit</persist>
</commit>
</rpc>
]]>]]>
<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
<close-session/>
</rpc>
]]>]]>
2 . session
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>
]]>]]>
<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<commit>
<persist-id>test_commit</persist-id>
</commit>
</rpc>
]]>]]>
<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<close-session/>
</rpc>
]]>]]>
hi,
The above scenario you mentioned works fine as expected.
But , I want to know what if we do not send commit or discard from second session.
that is,
I do some config from session 1 and send confirm commit with time-out as 100 sec and persist-id 1111 and close session.
Now, What happens after 100 sec??
I do not open session 2.
In my case the configuration remains without rollback.
Is this expected?? Please clarify
If you send commit in the same session
e.g.
<commit>
<persist-id>test_commit</persist-id>
</commit
then commit is confirmed and it will not be rollbacked. If you want to test it, use interactive mode
of netconf-console
Example:
netconf-console -i
In interactive mode you can paste NETCONF messages without closing the session. The <hello> message is not needed and your messages do not need <rpc ... > part. Each messages is separated with new line.
Example:
$ netconf-console -i
* Enter a NETCONF operation, end with an empty line
<edit-config>
<target>
<candidate/>
</target>
<config>
<hosts xmlns="http://tail-f.com/ns/example/host"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<host nc:operation="merge">
<name>thost</name>
<ip>192.168.1.33</ip>
</host>
</hosts>
</config>
</edit-config>
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<ok/>
</rpc-reply>
* Enter a NETCONF operation, end with an empty line
<commit>
<confirmed/>
<confirm-timeout>60</confirm-timeout>
<persist>test_commit</persist>
</commit>
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<ok/>
</rpc-reply>
* Enter a NETCONF operation, end with an empty line
(confirm within timout 60s)
<commit>
<persist-id>test_commit</persist-id>
</commit>
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<ok/>
</rpc-reply>
* Enter a NETCONF operation, end with an empty line
<close-session/>
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<ok/>
</rpc-reply>
If you don’t send
<commit>
<persist-id>test_commit</persist-id>
</commit>
Then commit is rollbacked within timeout (in this case 60s). You can see it in CLI:
Message from system at 2018-01-05 13:48:11...
confirmed commit operation not confirmed by admin from netconf
configuration rolled back
In case you do not get rollback, then something is incorrect.
Hi,
All the examples you gave here related to the same session.
But the goal of using persist-id is to have the ability to send another commit request using other session.
From RFC:
Used to issue a follow-up confirmed commit or a confirming
commit from any session, with the token from the previous
<commit> operation.
When we use the same session as you show in your example indeed it works.
Please try to use different session.
Thanks,
Evyatar
Hello,
yes, the latest example is from same session, as I understood you asked for it:
But the previous example is for 2 sessions (two netconf-console calls).
I have mentioned
session 1 and session 2. Can you describe why you think there is only one session?
Hi,
In my case I sent:
]]>]]>
eci-bgp:bgp
master
true
100
and after that I sent confirmed-commit:
]]>]]>
60
11111
9-Jan-2018::14:34:31.315 **< sess:21 write:
now I closed the session and open another one.
I did get-config and you can see that the timeout expired long time ago but the configuration is still there:
]]>]]>
<rt:routing xmlns:eci-bgp=“urn:eci:params:xml:ns:yang:eci-bgp” xmlns:rt=“urn:ietf:params:xml:ns:yang:ietf-routing”>
rt:control-plane-protocols
rt:control-plane-protocol
eci-bgp:bgp/
</rt:control-plane-protocol>
</rt:control-plane-protocols>
</rt:routing>
9-Jan-2018::14:38:16.055 **< sess:22 write:
true
100
Please assist.
Hi,
Sorry but my reply was corrupted.
Sending again my question:
I sent edit-config:
<nc:rpc message-id="urn:uuid:a5df243a-ab59-4016-9bd1-dfca1bd9684e" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:edit-config>
<nc:target>
<nc:candidate/>
</nc:target>
<nc:config>
<routing xmlns:eci-bgp="urn:eci:params:xml:ns:yang:eci-bgp" xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<control-plane-protocols>
<control-plane-protocol>
<type>eci-bgp:bgp</type>
<name>master</name>
<eci-bgp:bgp>
<eci-bgp:global>
<eci-bgp:enabled>true</eci-bgp:enabled>
<eci-bgp:as>345</eci-bgp:as>
</eci-bgp:global>
</eci-bgp:bgp>
</control-plane-protocol>
</control-plane-protocols>
</routing>
</nc:config>
</nc:edit-config>
</nc:rpc>
9-Jan-2018::14:24:27.419 **< sess:15 write:
<rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:a5df243a-ab59-4016-9bd1-dfca1bd9684e" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
After that I sent confirmed-commit:
<nc:rpc message-id="urn:uuid:38de85c7-2f08-4d7f-bfbe-34acab18a129" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:commit>
<nc:confirmed/>
<nc:confirm-timeout>60</nc:confirm-timeout>
<nc:persist>11111</nc:persist>
</nc:commit>
</nc:rpc>
9-Jan-2018::14:27:02.339 **< sess:16 write:
<rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:38de85c7-2f08-4d7f-bfbe-34acab18a129" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
The session was closed and I opened new session and after few minutes sent get-config on running:
<nc:rpc message-id="urn:uuid:7ed500e2-7d1f-4855-b520-f984bac60fb2" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:get-config>
<nc:source>
<nc:running/>
</nc:source>
<nc:filter type="subtree">
<rt:routing xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing" xmlns:eci-bgp="urn:eci:params:xml:ns:yang:eci-bgp">
<rt:control-plane-protocols>
<rt:control-plane-protocol>
<eci-bgp:bgp/>
</rt:control-plane-protocol>
</rt:control-plane-protocols>
</rt:routing>
</nc:filter>
</nc:get-config>
</nc:rpc>
9-Jan-2018::14:30:59.636 **< sess:18 write:
<rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:7ed500e2-7d1f-4855-b520-f984bac60fb2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<control-plane-protocols>
<control-plane-protocol>
<bgp xmlns="urn:eci:params:xml:ns:yang:eci-bgp">
<global>
<enabled>true</enabled>
<as>345</as>
</global>
</bgp>
</control-plane-protocol>
</control-plane-protocols>
</routing>
</data>
</rpc-reply>
The result show that the configuration still exist.
I noticed that CONFD printed error:
TRACE New user session: 16 for user:admin ctx:netconf --> CONFD_OK
TRACE CALL add_checkpoint_running() --> CONFD_OK
TRACE CALL data create(thandle=16,/routing/control-plane-protocols/control-plane-protocol{eci-bgp:bgp master}/bgp) --> CONFD_ACCUMULATE
TRACE CALL data set_elem(thandle=16, /routing/control-plane-protocols/control-plane-protocol{eci-bgp:bgp master}/bgp/global/enabled, true) --> CONFD_ACCUMULATE
TRACE CALL data set_elem(thandle=16, /routing/control-plane-protocols/control-plane-protocol{eci-bgp:bgp master}/bgp/global/as, 345) --> CONFD_ACCUMULATE
TRACE CALL trans prepare(thandle=16) --> CONFD_OK
TRACE CALL trans commit(thandle=16) --> CONFD_OK
TRACE CALL trans finish(thandle=16) --> CONFD_OK
TRACE Close user sess 16
--> CONFD_OK
INTERNAL ERROR: Got 71 op on non existing user sess 16
--> CONFD_ERR
please assist,
Hi,
Can you please help us solve this issue?
confirmed-commit doesn’t rollback the configuration when using persist-id.
Once the session close the configuration became persist.
Thanks,
Evyatar
What are these set_elem calls used for? Is it data model transformation?
My guess is the rollback failed in one of your callbacks (set_elem??).
This is due to a bug that has been fixed for upcoming versions, but it “only” affects configuration handled by external data providers - i.e. they won’t receive the activate_checkpoint_running() callback invocation that tells them to revert the changes to running in this case. Does this match your case, i.e. the config you are changing in the edit-config is handled by an external data provider?
Edit: Sorry, stupid question, since your CONFD_TRACE output clearly shows that this is the case…
Hi Per ,
Do we have the fix ready for this issue in confd 7.3 basic version?
I would certainly hope so, since I claimed that it was fixed 2 years ago.
A bit of digging in old CHANGES finds this note for ConfD-6.6 [March 01, 2018]:
- confd: If a confirmed commit with persist timed out after the client
session had closed, an external dataprovider would not be invoked in
activate_checkpoint_running(). This bug has been fixed.
(ENG-13140, RT:24397, RT:28656, PS-7745, PS-9187)
This implies that it is also fixed in ConfD-6.7 and all ConfD-7.x versions. (ConfD Basic always has the same fixes, as long as the relevant components are included at all.)
Thanks Per for the confirmation.