Featured image of post Netconf: Fix 'resource denied: Sync is in progress'

Netconf: Fix 'resource denied: Sync is in progress'

We show you how to solve the 'resource denied: Sync is in progress' error

Home / Posts / Netconf: Fix 'resource denied: Sync is in progress'

When you work with Netconf, sometimes you could face the issue “resource denied: Sync is in progress” This error can be solved by locking & unlocking the config for each call. Read on to see how you can do this in Python & Go.

What is Netconf?

Netconf, or Network Configuration Protocol, is a powerful network management protocol developed by the Internet Engineering Task Force (IETF). With its ability to manipulate and control device configuration data using XML-based data encoding, it surpasses traditional CLI-based configurations in terms of scalability, programmability, and precision.

It leverages a RPC-like mechanism for communication between clients and servers, and supports various operations like ‘get’, ’edit-config’, ‘copy-config’, ‘delete-config’, etc., providing a comprehensive set of tools for network configuration tasks.

Moreover, it’s well-suited for managing devices in large-scale networks as it can easily handle bulk configurations and changes. Using Netconf can also greatly minimize the risk of network configuration errors, thanks to its transaction-oriented configuration changes that allow for atomic commit and rollback of configuration changes. If you’re striving for enhanced network automation, programmability, and error-free configuration management, utilizing Netconf is a must.

When can you face the “resource denied: Sync is in progress” error?

When you do multiple config changes in short succession, you can run into the “resource denied: Sync is in progress” error. This will happen because the configuration store is still syncing and not ready for another configuration change.

Example full error

1
2
3
4
<error-message xml:lang="en">resource denied: Sync is in progress</error-message>
<error-info>
	<bad-element>default</bad-element>
</error-info>

How to solve it?

The proper way to solve this issue, or to be more specific, to ensure to never run into it, is always to lock & unlock the datastore. Before & after each RPC Call, you should lock and unlock your datastore.

Python Example

If you are using python and the ncclient library you can simple use the following code

1
2
3
m.lock(target="running")
m.edit_config(target="running", config=config)
m.unlock(target="running")

Go Example

If you are using Go and the Juniper Netconf Library then you have to implement the locking & unlocking yourself.

This is a basic example, but should help to point you into the right direct.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
func unlockDatastore(s *netconf.Session) (result string, err error) {
	raw := netconf.RawMethod(`<unlock><target><running/></target></unlock>`)
	reply, err := s.Exec(raw)
	if err != nil {
		return "", err
	}
	return reply.Data, nil
}

func lockDatastore(s *netconf.Session) (result string, err error) {
	raw := netconf.RawMethod(`<lock><target><running/></target></lock>`)
	reply, err := s.Exec(raw)
	if err != nil {
		return "", err
	}
	return reply.Data, nil
}

Additional Information

comments powered by Disqus
Built with Hugo
Theme Stack designed by Jimmy