cmlsh multiple-config-session
Use this command to enable or disable multiple CLI sessions to enter into configuration mode simultaneously.
With this support, multiple CLI users can enter into configuration mode simultaneously and do configurations in parallel and commit into the running datastore. This is similar to NetConf multiple session support described in RFC 6241.
When multiple configuration mode sessions are disabled, only one user can enter configuration mode and it will lock the running datastore.
If any CLI session is already there in configuration mode, error will be given when user tries to enable this mode.
A datastore lock can be acquired using the
cml lock config-datastore command if you want to do configuration without fear of interaction with other user sessions.
This command is available only to users with the network-admin role.
This configuration is retained across reboots.
Command Syntax
cmlsh multiple-config-session (enable|disable)
Parameters
enable
Enable multiple configuration mode sessions.
disable
Disable multiple configuration mode sessions.
Default
By default, multiple CLI sessions are disabled.
Mode
Exec mode
Applicability
This command was introduced in OcNOS version 5.1.
Example
#cmlsh multiple-config-session enable
#
#show cmlsh multiple-config-session status
CMLSh multiple configuration session mode : Enabled
#
Usage
Multiple users can enter into configuration mode simultaneously and do configurations in parallel and commit into the running datastore. Examples of when you need this feature are:
• Migrating to replace an existing device. If an existing device has a large configuration and it is only done by one person, it will take more time to configure. If multiple users can configure at same time, it will take less time.
• Troubleshooting and operating. Sometimes a single device has 2 or more links to troubleshoot. If only one user only can do configuration, it will take more time to resolve the problem.
When multiple sessions are doing parallel configurations, there is a chance that one user’s configuration might conflict with another user’s configuration.
If you do not lock the datastore before doing a configuration, a parallel candidate datastore can be created and will be allowed to commit to the datastore. So the datastore can change while the previous user is still having the configuration in its candidate. Now when the previous user tries to commit, if the configurations conflict, it will fail.
For example, if the previous user was adding a BGP neighbor and the BGP router itself is removed from the datastore via the parallel transaction, when this user tries to commit, it will fail. The reason is when commands are added to candidate, it only checks the running datastore at that point and allows them to be added to candidate configuration datastore. But later if the running datastore itself is changed, these configurations can be irrelevant and will cause an error on commit. So the user will have to abort the transaction.
Last modified date: 10/19/2023