Specifically, the following additional events are modified:

• panic-on-io-nmi
• panic-on-unrecovered-nmi

The reboot delay time following a kernel panic was also modified from 60 seconds to 30 seconds:

• reboot-wait-after-panic = 30

VRVDR-52568 reverts the defaults in 1912f such that the system no longer panics on the additional events. The reboot wait timer is also reverted to 60 seconds. The CLI to change the behavior through configuration remains; only the default behavior has changed. No change is made to the panic-of-oops default – it remains set.

Confirmed commit helps guard against committing configurations which can cause loss of connection to the system being managed, or perhaps the configuration being committed causes system instability or crashes. Such scenarios are automatically recovered from if the configuration is not confirmed, reverting back to the last working configuration. The confirmed commit capability is the NETCONF equivalent feature, which has the same goals, but slightly different way of operating. The confirmed commit features and functionality are described in RFC 6241, Section 8.4:

"The :confirmed-commit:1.1 capability indicates that the server will support the cancel-commit operation and the confirmed, confirm-timeout, persist, and persist-id parameters for the commit operation. See Section 8.3 for further details on the commit operation.

A confirmed commit operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a commit operation without the confirmed parameter. The timeout period can be adjusted with the confirm-timeout parameter. If a follow-up confirmed commit operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up confirmed commit operation MAY introduce additional changes to the configuration.

If the persist element is not given in the confirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the confirmed commit. If the persist element is given in the confirmed commit operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a persist-id element with a value equal to the given value of the persist element.

If the server also advertises the :startup capability, a copy-config from running to startup is also necessary to save the changes to startup."

Confirmed-commit

<rpc message-id="1234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
	<commit> 
        	<confirmed/> 
	</commit> 
</rpc>

Confirm-timeout

A confirmed-commit is reverted if it is not confirmed within 10 minutes. An alternative timeout can be specified using the confirm-timeout parameter. The confirm-timeout specifies the number of seconds, after which a confirmed-commit is reverted. The confirm-timeout accepts the values 1 through 4294967295 seconds. Other values are rejected as an error. The confirm-timeout is canceled once the commit is confirmed.

<rpc message-id="1993" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<commit>
		<confirmed/>
		<confirm-timeout>900</confirm-timeout>
	</commit>
</rpc> 

Revert on session termination

If the session on which a confirmed-commit is issued terminates before the confirm-timeout expires, the configuration is restored to the state before the confirmed-commit was issued. This behavior can be over-ridden by specifying a persist parameter in the confirmed-commit.

Persistent confirmed-commit

The behavior specified in the previous requirement  can be overridden to allow the confirmed-commit to survive the termination of the session by specifying a persist parameter. When present, the confirmed-commit is persistent, surviving the termination of the session on which the confirmed-commit was issued. The persist value must then be used when confirming the confirmed-commit. It is simply a string value.

<rpc message-id="2371" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<commit>
		<confirmed/>
		<confirm-timeout>300</confirm-timeout>
		<persist>NCC-74656</persist>
	</commit>
</rpc> 

Follow-up confirmed-commit

If a confirmed-commit is received, while another confirmed commit is ongoing, that is it has not yet been confirmed, the confirmed commit is considered a follow-up commit. For a follow-up confirmed-commit, the confirm-timeout is restarted, using the confirm-timeout value derived from the follow-up commit operation. Any configuration changes are regarded as additional changes on top of any preceding confirmed commit. If no confirming-commit happens before the expiry of the last confirm-timeout, the configuration is reverted back to the state before the initial confirmed-commit.

A follow-up confirmed-commit must have a persist-id value which matches the persist value of the initial confirmed-commit, if the persist-id does not match an ongoing confirmed-commit, the follow-up confirmed commit is rejected with an invalid-value error. If no persist value was present in the initial confirmed-commit, no persist-id parameter should be present in the follow-up, and the follow-up commit must be received on the same session.

<!-- Initial confirmed-commit --> 
<rpc message-id="2371" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
	<commit> 
		<confirmed/>
		<confirm-timeout>300</confirm-timeout> 
		<persist>NCC-74656</persist> 
	</commit>
</rpc> 

<!-- Follow-up confirmed-commit, with new timeout value and uses persist-id matching persist of initial commit --> 
<rpc message-id="2375" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
	<commit>
		<confirmed/>
		<confirm-timeout>500</confirm-timeout>
		<persist-id>NCC-74656</persist-id>
	</commit> 
</rpc> 

<!-- Final confirming-commit, which confirms the sequence of commits identified by persist-id NCC-74656 -->
<rpc message-id="2378" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
	<commit> 
		<persist-id>NCC-74656</persist-id>
	</commit> 
</rpc> 

Confirming-commit

A confirming-commit is any commit operation without the confirmed parameter, that is issued before the confirm-timeout expires. When received, the confirmed-commit is confirmed, and the confirm-timeout is canceled. The confirming-commit must be issued on the same session as the commit being confirmed, unless the confirmed-commit has a persist parameter.

At present, if a NETCONF commit operation is issued, and there are no configuration changes to commit, an error is reported, specifying that there are no changes to commit. This error is not reported, if it is determined that the commit operation is a confirming-commit. If there are no outstanding confirmed-commits, the error is reported as usual. If there are any configuration changes which can be committed when a confirming-commit is received, these are committed as normal. If the confirming-commit is a valid confirmed-commit, the new confirmed-commit is considered as a new independent confirmed-commit, even if identified by the same persist parameter as the confirmed commit being confirmed.

<!-- Confirming a confirmed-commit, on same session. There may or may not be additional changes being committed. -->
<rpc message-id="2001" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
	<commit/> 
</rpc> 

 <!-- Confirming a confirmed-commit which had a <persist> parameter of "NX-01". This can be issued on the same session or a different session to the original confirmed-commit. Any additional changes are committed as normal, i.e. not as a confirmed-commit --> 
<rpc message-id="2151" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<commit>
		<persist-id>NX-01</persist-id>
	</commit>
</rpc

Persist-id

The persist-id parameter must be used to confirm a confirmed-commit that had a persist parameter. It also allows a confirmed-commit to be confirmed on any session, not just the session on which the confirmed-commit was issued. The persist-id must equal the persist parameter specified in the confirmed-commit, if it does not match an outstanding confirmed-commit, the confirming-commit fails with an invalid-value error.

Cancel a persistent confirmed-commit

The cancel-commit operation can cancel a persistent confirmed commit by specifying the confirmed-commits persist value in the persist-id parameter. A persistent confirmed-commit can be canceled from any session.

If an ongoing confirmed commit cannot be identified that matches the persist-id parameter, the cancel-commit operation fails with an invalid-value error.

<rpc message-id="2266" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<cancel-commit>
		<persist-id>NCC-1701</persist-id>
	</cancel-commit>
</rpc>

Show system confirmed-commits

A show system confirmed-commits command is available, to show the status of any confirmed-commits. If possible, it shows the session on which the confirmed-commit was issued, any persist value and the confirm-timeout outstanding at the time the command was invoked.

vyatta@vm-fl3-1:~$ show system confirmed-commit Session Revert Time Persist-Id 2865 2020-03-23 09:25:00 ABDpersist123 vyatta@vm-fl3-1:~$

Cancel confirmed-commit

There is a cancel confirmed-commit command to allow a confirmed-commit, with an associated persist value to be canceled from the CLI. This command is available in configuration mode.

The syntax of the command is as follows:

cancel-commit [ force | persist-id <persist-id> ]  [ comment <comment-text> ]

Multiple session interaction

RFC 6241 talks about using the lock operations to avoid undesirable consequences of multiple sessions updating the configuration. vRouter's current lock implementation only supports locking of the candidate datastore, which does not seem to offer any useful utility. Each session maintains its own independent candidate datastore and locking the candidate by using NETCONF still allows other CLI sessions to make and commit configuration changes. Supporting a lock on the running configuration is required to allow useful confirmed-commit operation without other sessions changing the configuration.

Improved lock support

The NETCONF lock operation supports locking of the running configuration. This allows a client to safely lock the running configuration until it has completed a series of edit-config, commit.

A NETCONF client can only lock the running configuration if the following criteria are satisfied:

• The lock is not currently held by another session. On vRouter, the running configuration is implicitly locked when committing.

• Another session has an ongoing confirmed-commit, that is one which has not yet been confirmed.

CLI confirmation of a NETCONF confirmed-commit

<!-- A NETCONF confirmed commit -->  
<rpc message-id="2364" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<commit>
		<confirmed/>
		<confirm-timeout>300</confirm-timeout>
		<persist>NCC-1701-D</persist>
	</commit>
</rpc> 

<!-- Can be confirmed by the CLI -->
vyatta@vm-commit-1# confirm persist-id "NCC-1701-D"

Advertise confirmed-commit capability

To inform NETCONF clients that the vRouter supports the confirmed-commit capability, the confirmed-commit capability should be advertised as part of the NETCONF hello message.

The capability string used to indicate this, as specified in RFC 6241; Sec 8.4.3, is:

urn:ietf:params:netconf:capability:confirmed-commit:1.1

<?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>	
		<capability>urn:ietf:params:netconf:base:1.1</capability>
		<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all,explicit</capability>
		<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
		<capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
		<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
		<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>
		<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
		<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
	</capabilities>
	<session-id>1</session-id>
</hello> 

Include persist-id

The NETCONF confirmed-commit feature uses the same infrastructure as confirm-commit and rollback. Any logs which are currently generated are enhanced to include the persist-id, and indicate that the commit is a confirmed-commit originating from a NETCONF session.