So i want to write an EEM that basically starts a seperate script where i check what user is logged on, to which group it belongs and then define if they can or cannot run the command. Example:

event manager applet FILTERCMD
  event cli pattern "^interface GigabitEthernet1/0/[0-9]+$" sync yes
  action 001 cli command "enable"
  action 002 cli command "tclsh flash:/filtercmd.tcl $_cli_cmd"
  action 003 set _exit_status "$_cli_result"

So here, i want to run filtercmd.tcl with the exact command entered as a variable. In my example i used $_clie_cmd as a placeholder. What im looking for is the correct variable to achieve my goal. Once the TCL script has run it will either return 0 (prevent the command from running) or return 1 (allow the command to run). The variable $_cli_result contains the output after running the tcl script.

So basically if user A loggs in and issues

interface GigabitEthernet1/0/2

he is allowed to run the command, but if user B loggs in and issues the same command, it is getting blocked. Another use case, if user A tries to run a different interface like:

interface GigabitEthernet1/0/19

we may want to block it, even though we allowed interface Gi1/0/2.

So im not looking for any content for filtercmd.tcl, i only want to know how to get the exact command entered into an argument for calling the filtercmd.tcl script.

I have tried to realize this with an event manager policy but the scripts there are running in a safe-tcl environment and are very slow. It takes over 700ms to just get the output of the show users wide command. And i plan on doing a whole lot more than that. So i dont want to have a 3s lag every time i try to enter a command.

2 Answers 2


Cisco already has that functionality via the privilege level configuration and the AAA authorization features. You can group commands by privilege level and assign users to matching levels to limit their abilities.





Doing it on an 'interface by interface' level is not practical. Any staff member with access to change configuration of one interface should essentially have access to change any interface. If that is not acceptable, it suggests your network design is not appropriate for the security policies and physical environment where the network is deployed.

Essentially you are trying to do this the 'wrong way' and the performance issue you see is a result of that design. If you want to limit access to configuration to a particular network segment (specific interfaces that serve a limited part of the network) then you should provision separate equipment for those segments and allow them access as needed on that equipment. That or use a virtualized router design where you can dedicate a virtual router per segment where you want to limit access.

  • i want to allow or deny certain scripts that can be run via tclsh and with your solution, i can either allow or deny all tclsh scripts. I explicitly used an example with an interface to avoid these "you are doing it wrong, just use privilidge levels for that" answers. So your answer does not help me at all. Thanks for taking the time though, maybe it helps someone else that stumbles on this thread in the future.
    – Mario Jost
    Commented Apr 16 at 13:46

The correct variable is called $_cli_msg as pointed out by Dan Frey from the cisco forum.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.