• Config Sessions Tips

 
 
Print Friendly, PDF & Email


Description:

This article shows how to implement 4-eyes-principle, task separation and delegation in your network. In this particular example, 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.

Since this article has been published, there have been quite a few improvements to the way EOS handles configurations sessions. Please refer to “Config Checkpoint” and “Config Session Commit Timer” for further details. We’ll keep this article unchanged as a showcase of potential EOS flexibility.


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. Furthermore, they are 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.

In our example, we’re creating local users in these roles, one for each.

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#
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, he 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.gz
spine1#
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#
Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: