ConfD User Community

Regarding confirmed-commit operation


#1

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 ??


#2

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).


#3

It works fine. Meaning, configuration gets reverted after 600 sec(default) or any other specified time.

Can someone please answer my above question?


#4

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


#5

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>
]]>]]>

#6

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


#7

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.


#8

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


#9

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?


#10

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.


#11

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,


#12

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


#13

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??).


#14

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…