In the cisco ASA, we have the means to config term but did you know you have a config session option?
Almost every uses the config terminal in a day to day operations, but the config session has it's own benefits.
1: Here's a few of the highlights;
> it allows you to deploy configuration at a later time
( e.g your working on a large ACL and need to take a cafe break or go out to lunch )
> it provides a delay time to review any configurations before committal
( great if you have OPS group that QA fwpolicies changes)
> configuration are manually commit by the user
( by the creator or another... great if you a administrator and senior lead you commits the changes after review and approval )
> you can abort or revert any change in the configuration process
( e.g your configuration a new ACL for specific filtering event and later you need to abort the configuration )
> !!!!!WARNING configuration sessions don't survive reboots/power lost or synced to any slaves WARNING!!!!
With the config session is easy to deploy. Just craft a name for the session. The name can be any characters and with a limit in the length of the session_name to 32 characters;
in most MSSP we have used case/tickets# or change_control_numbers# in our names and that seems to works out great
And you can only have a max of 3 config sessions active at any one time and the ASA will deliver a warning if you try to exceed that;
The session name can also start with !#@ but can not contain any spaces
The uses of the config session is a must in a SOC/MSSP arena where you have numerous changes underway IMHO.
Here's a dialog of a session name TEXT using the session command for a access-list creation
config session test
access-list KENFELIX remark BLOG
access-list KENFELIX line 10 permit tcp host 184.108.40.206 host 220.127.116.11 eq 22
notice how the changes are shown as un-committed, when executing the show configure session command ?
Now we can, at this point either commit or abort the changes after re-execution of our config session <session name >. If we decide on starting a new session we will be warn of the pending session.
Also the ACL list is not part of the running or saved startup configuration since it was never committed.
If we so happen to abort the session, all changes would be eliminated.
up to this point nothing has been changed
If we should issue a commit noconform the changes would be pushed into the running-config & the session will be completed and terminated.
It you find any sessions that needs to be eliminate, please use the clear configuration session command
show configure session
configure session !123456789012345688901234567890 (un-committed)
clear configuration session !12345678901234568890123456$
It's advisable to review all pending config sessions before starting a new sessions
I've worked with a few SOC groups that fought over configurations and you will find that 2 operators configuring the same item & causing confusion can be avoid.
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix -----a----t---- socpuppets ---dot---com
=( * * )=