Config Sessions Tips


Description:

You want to implement human error prevention, 4-eyes-principle, task separation and delegation in your network? Then read on. We’ll show you how you can delegate configuration preparation to the operators team, retaining the control to commit the submitted changes, and having a delayed roll-back as a safety network in case something went wrong.

Please also refer to the article “How to keep last X startup configs” for further tips on config handling and versioning.


User Management:

Let’s create two roles: one for the Network Operations team, that is allowed to use “configure session” to prepare changes, but is not allowed to use “commit” to make these changes active. Of course they are also not allowed to use direct configuration to bypass the config sessions.

The second role is for our eAPI client, that will request the rollback to previously saved config (the “startup-config”). This is the only allowed command for this user, due to security concerns, as we will have his username and password in clear text in our config.

role netops 10 permit mode exec command configure session 20 deny mode exec command configure|bash|python-shell|\| 30 deny mode config command commit 40 permit mode exec command .* 50 permit mode config-all command .* ! role rb-only 10 permit mode exec command configure replace startup-config

Now we’ll set local authorization for exec (“enable” mode) and commands. We’ll also enable authorization on the serial console, as it’s not active per default. Of course the same is possible with an external RADIUS/TACACS server, or a combination: remote authentication, local authorization.

We’re also creating local users in these roles, one for each. We highly recommend using different passwords in your setup! ;-)

aaa authorization console aaa authorization exec default local aaa authorization commands all default local ! username eapi privilege 15 role rb-only secret 0 eapi username oper privilege 15 role netops secret 0 oper123


Other Preparations:

As the command to revert to a previously saved config is always (in this setup) “configure replace startup-config”, we can prepare a static file with the corresponding JSON request and use it when needed (here with the optional “ignore-errors” parameter). The creation of this file is triggered “on-boot” in the configuration below, but you can choose any other option, of course. Important is only that the file gets created before you start using the “rb” alias that we define in the next step.

We also enable the eAPI access (here with HTTPS per default).

event-handler rollback-json
   trigger on-boot
   action bash echo '{"jsonrpc":"2.0", "method":"runCmds", "params":{ "version":1, "cmds": [ "configure replace startup-config ignore-errors" ], "format":"json", "timestamps":false }, "id":"rollback.json"}' > /mnt/flash/rollback.json
   delay 0
   asynchronous
!
management api http-commands
   no shutdown

And finally, the “rb” alias itself, with complementary “norb” to cancel roll-back:

alias rb bash NL=$'\n'; FastCli -p 15 -c "configure $NL schedule rollback at `date -d "now + %1 minutes" +%T` once max-log-files 10 logging verbose command bash curl -k -d @/mnt/flash/rollback.json https://eapi:eapi@localhost/command-api --header Content-Type:application/json"
!
alias norb bash NL=$'\n'; FastCli -p 15 -c "configure $NL no schedule rollback"


How it works:

Your operators team can now prepare configuration suggestions using “configure session SessionName” (if you skip SessionName, the name will be auto-generated). Upon finishing the preparation, they will tell the administrators team the session name (as they are not allowed to commit changes themselves).

 spine1#show users
Line User Host(s) Idle Location 1 tty
1 admin idle 04:53:00 - 2 vty
4 admin idle 01:33:00 192.168.18.1 * 
3 vty 6 oper idle 00:00:26 192.168.18.1

spine1#
spine1#show aaa sessions
Session Username Roles TTY State Duration Auth Remote Host
-------- --------- -------------- ----- ------- ---------- ------- ------------
27 admin network-admin tty1 E 5:10:05 local
33 admin network-admin ssh E 4:34:43 local 192.168.18.1
50 oper netops ssh E 0:02:24 local 192.168.18.1

spine1#
spine1#conf % Authorization denied for command 'configure'
spine1# spine1#conf session
spine1(config-s-sess0)#hostname spine-1
spine1(config-s-sess0)#
spine1(config-s-sess0)#commit
% Authorization denied for command 'commit'
spine1(config-s-sess0)#show configuration sessions
Maximum number of completed sessions:
1 Maximum number of pending sessions:
5 Name State User Terminal
 ----- ------------- ---------- --------
* sess0 pending oper vty6
spine1(config-s-sess0)#end
spine1#

 

A member of the admin team will enter this session and review the changes using “show session-config diffs”.
If he approves the changes, he will verify the difference between the currently running config and the saved copy, using “show run diff” — there should be no difference at this stage. Now he can use “rb” and the time in minutes to set up a delayed roll-back to the currently saved startup-config, and after spanning this safety net he can finally “commit” changes in the config session, making them active.

spine1#show users 
Line User Host(s) Idle Location 
1 tty 1 admin idle 26w5d - 
2 vty 4 admin idle 26w5d 
192.168.18.1 * 3 vty 
6 admin idle 00:00:06 192.168.18.1

spine1#show aaa sessions 
Session Username Roles TTY State Duration Auth Remote Host 
-------- --------- -------------- ----- ------- ---------- ------- ------------ 
27 admin network-admin tty1 E 5:26:20 local 
33 admin network-admin ssh E 4:50:59 local 192.168.18.1 
51 admin network-admin ssh E 0:00:20 local 192.168.18.1

spine1#config session sess0 
spine1(config-s-sess0)#show session-config diffs 
--- system:/running-config 
+++ session:/sess0-session-config 
@@ -21,7 +21,7 @@ 
! logging host 172.16.130.10 
! 
-hostname spine1 
+hostname spine-1 
ip name-server vrf default 172.16.130.10 
ip domain-name ztps-test.com 
! 
spine1(config-s-sess0)#show run diffs
spine1(config-s-sess0)#rb 5 
spine1(config-s-sess0)#commit 
spine-1#

If everything worked as expected, you can cancel the pending roll-back using "norb":

spine-1#show schedule summary 
Name At time Last Inter\ Max Logfile Location Status time val log (mins) files 
----------- ----------- ----- ------ ----- ----------------------------- ------ 
rollback 20:57:26 - once 1 - Waiting 02/05/2016 
tech-support now 20:52 60 100 flash:/schedule/tech-support/ Success 

spine-1# 
spine-1#show clock 
Fri Feb 5 20:52:57 2016 Timezone: UTC Clock source: local 


spine-1#norb
spine-1#show schedule summary 
Name At time Last Inter\ Max Logfile Location Status time val log (mins) files
 ------------ ------- ----- ------- ------ ------------------------------ ------ 
tech-support now 20:52 60 100 flash:/schedule/tech-support/ Success spine-1#

If something did not work out well, the roll-back will fire at the set time, and you will get notified about it in the syslog and more detailed in the specific scheduler file under "flash:schedule/rollback".

spine1#
spine1# show log 2 
Feb 5 21:10:05 spine1 CapiApp: %SYS-5-CONFIG_REPLACE_SUCCESS: User eapi replaced running configuration with flash:/startup-config successfully on command-api (127.0.0.1) 
Feb 5 21:10:08 spine1 SuperServer: %SYS-7-CLI_SCHEDULER_JOB_COMPLETED: The scheduled CLI execution job 'rollback' completed successfully.Logfile is stored in flash:/schedule/rollback/rollback_2016-02-05.2109.log.gzspine1#

spine1# bash zcat /mnt/flash/schedule/rollback/rollback_2016-02-05.2109.log.gz 
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 
100 241 100 57 100 184 21 68 0:00:02 0:00:02 --:--:-- 
67 {"jsonrpc": "2.0", "result": [{}], "id": "rollback.json"}
spine1#
spine1#