Often times, in production network we need to know if a specific command is present in a device or not. if present, we need to find out how many of the device has this configuration present.
Such use-cases are the most frequently visited examples in Network operations.
To do this, we can use a inbuilt function of NAPALM module called as “load_config”.
For demonstration – we need to figure out the status(i.e. availability) of specific command “ntp server 1.1.1.1” on all the network router running IOS.
To understand the complete documentation of this function – we can use below command as discussed in previous section
root@mrcissp-master-1:/# salt 'R*' sys.doc net.load_config
net.load_config:
Applies configuration changes on the device. It can be loaded from a file or from inline string.
If you send both a filename and a string containing the configuration, the file has higher precedence.
By default this function will commit the changes. If there are no changes, it does not commit and
the flag ``already_configured`` will be set as ``True`` to point this out.
To avoid committing the configuration, set the argument ``test`` to ``True`` and will discard (dry run).
To keep the changes but not commit, set ``commit`` to ``False``.
To replace the config, set ``replace`` to ``True``.
filename
Path to the file containing the desired configuration.
This can be specified using the absolute path to the file,
or using one of the following URL schemes:
- ``salt://``, to fetch the template from the Salt fileserver.
- ``http://`` or ``https://``
- ``ftp://``
- ``s3://``
- ``swift://``
Changed in version 2018.3.0
text
String containing the desired configuration.
This argument is ignored when ``filename`` is specified.
test: False
Dry run? If set as ``True``, will apply the config, discard and return the changes. Default: ``False``
and will commit the changes on the device.
commit: True
Commit? Default: ``True``.
debug: False
Debug mode. Will insert a new key under the output dictionary, as ``loaded_config`` containing the raw
configuration loaded on the device.
New in version 2016.11.2
replace: False
Load and replace the configuration. Default: ``False``.
New in version 2016.11.2
commit_in: ``None``
Commit the changes in a specific number of minutes / hours. Example of
accepted formats: ``5`` (commit in 5 minutes), ``2m`` (commit in 2
minutes), ``1h`` (commit the changes in 1 hour)`, ``5h30m`` (commit
the changes in 5 hours and 30 minutes).
Note:
This feature works on any platforms, as it does not rely on the
native features of the network operating system.
Note:
After the command is executed and the ``diff`` is not satisfactory,
or for any other reasons you have to discard the commit, you are
able to do so using the
:py:func:`net.cancel_commit <salt.modules.napalm_network.cancel_commit>`
execution function, using the commit ID returned by this function.
Warning:
Using this feature, Salt will load the exact configuration you
expect, however the diff may change in time (i.e., if an user
applies a manual configuration change, or a different process or
command changes the configuration in the meanwhile).
New in version 2019.2.0
commit_at: ``None``
Commit the changes at a specific time. Example of accepted formats:
``1am`` (will commit the changes at the next 1AM), ``13:20`` (will
commit at 13:20), ``1:20am``, etc.
Note:
This feature works on any platforms, as it does not rely on the
native features of the network operating system.
Note:
After the command is executed and the ``diff`` is not satisfactory,
or for any other reasons you have to discard the commit, you are
able to do so using the
:py:func:`net.cancel_commit <salt.modules.napalm_network.cancel_commit>`
execution function, using the commit ID returned by this function.
Warning:
Using this feature, Salt will load the exact configuration you
expect, however the diff may change in time (i.e., if an user
applies a manual configuration change, or a different process or
command changes the configuration in the meanwhile).
New in version 2019.2.0
revert_in: ``None``
Commit and revert the changes in a specific number of minutes / hours.
Example of accepted formats: ``5`` (revert in 5 minutes), ``2m`` (revert
in 2 minutes), ``1h`` (revert the changes in 1 hour)`, ``5h30m`` (revert
the changes in 5 hours and 30 minutes).
Note:
To confirm the commit, and prevent reverting the changes, you will
have to execute the
:mod:`net.confirm_commit <salt.modules.napalm_network.confirm_commit>`
function, using the commit ID returned by this function.
Warning:
This works on any platform, regardless if they have or don't have
native capabilities to confirming a commit. However, please be
*very* cautious when using this feature: on Junos (as it is the only
NAPALM core platform supporting this natively) it executes a commit
confirmed as you would do from the command line.
All the other platforms don't have this capability natively,
therefore the revert is done via Salt. That means, your device needs
to be reachable at the moment when Salt will attempt to revert your
changes. Be cautious when pushing configuration changes that would
prevent you reach the device.
Similarly, if an user or a different process apply other
configuration changes in the meanwhile (between the moment you
commit and till the changes are reverted), these changes would be
equally reverted, as Salt cannot be aware of them.
New in version 2019.2.0
revert_at: ``None``
Commit and revert the changes at a specific time. Example of accepted
formats: ``1am`` (will commit and revert the changes at the next 1AM),
``13:20`` (will commit and revert at 13:20), ``1:20am``, etc.
Note:
To confirm the commit, and prevent reverting the changes, you will
have to execute the
:mod:`net.confirm_commit <salt.modules.napalm_network.confirm_commit>`
function, using the commit ID returned by this function.
Warning:
This works on any platform, regardless if they have or don't have
native capabilities to confirming a commit. However, please be
*very* cautious when using this feature: on Junos (as it is the only
NAPALM core platform supporting this natively) it executes a commit
confirmed as you would do from the command line.
All the other platforms don't have this capability natively,
therefore the revert is done via Salt. That means, your device needs
to be reachable at the moment when Salt will attempt to revert your
changes. Be cautious when pushing configuration changes that would
prevent you reach the device.
Similarly, if an user or a different process apply other
configuration changes in the meanwhile (between the moment you
commit and till the changes are reverted), these changes would be
equally reverted, as Salt cannot be aware of them.
New in version 2019.2.0
saltenv: ``base``
Specifies the Salt environment name.
New in version 2018.3.0
:return: a dictionary having the following keys:
* result (bool): if the config was applied successfully. It is ``False`` only in case of failure. In case there are no changes to be applied and successfully performs all operations it is still ``True`` and so will be the ``already_configured`` flag (example below)
* comment (str): a message for the user
* already_configured (bool): flag to check if there were no changes applied
* loaded_config (str): the configuration loaded on the device. Requires ``debug`` to be set as ``True``
* diff (str): returns the config changes applied
CLI Example:
salt '*' net.load_config text='ntp peer 192.168.0.1'
salt '*' net.load_config filename='/absolute/path/to/your/file'
salt '*' net.load_config filename='/absolute/path/to/your/file' test=True
salt '*' net.load_config filename='/absolute/path/to/your/file' commit=False
Example output:
{
'comment': 'Configuration discarded.',
'already_configured': False,
'result': True,
'diff': '[edit interfaces xe-0/0/5]+ description "Adding a description";'
}
We can observe – When executing in test mode (dry run), we do not
apply any changes in the running configuration of the device.
root@mrcissp-master-1:/# salt -C 'G@os:ios' net.load_config text='ntp server 1.1.1.1' test='True'
Router1:
----------
already_configured:
False
comment:
Configuration discarded.
diff:
+ntp server 1.1.1.1
loaded_config:
result:
True
Based on the output “already_configured” is set to “False” i.e. this specific command was not found the running configuration of the Router.
Comment: Configuration discarded – Since, we ran above command in Dry run mode therefore configuration was never applied to the network device running config.
We can extend the same example to a set of configuration command present in a file. Let’s assume we want to check if below commands are present in a Router.
- ntp server 1.1.1.1
- ntp server 2.2.2.2
- hostname Router_1
- router ospf 2
To do this job, we can create a check_config.cfg file in the same directory mentioned by file_root configuration in Master configuration file.
root@mrcissp-master-1:/etc/salt/templates# pwd /etc/salt/templates root@mrcissp-master-1:/etc/salt/templates# cat check_config.cfg ntp server 1.1.1.1 ntp server 2.2.2.2 hostname Router_1 router ospf 2
We can call this file in load_config function as below
root@mrcissp-master-1:/etc/salt/templates# salt 'Router*' net.load_config salt://check_config.cfg test='True'
Router1:
----------
already_configured:
False
comment:
Configuration discarded.
diff:
+ntp server 1.1.1.1
+ntp server 2.2.2.2
+hostname Router_1
+router ospf 2
loaded_config:
result:
True
