cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1138
Views
0
Helpful
7
Replies

EEM - Applet Help Appreciated

I am using the following applet to modify entries in two ACLs from a mobile device. Please see applet below with output from a test run:

3    applet    user    none                Off   Sun Mar 28 22:42:59 2010  rite1

policyname {rite1} sync {yes}

maxrun 60.000

action 1.0 puts "Set HostA:"

action 1.1 gets hosta

action 1.2 puts "Set HostB:"

action 1.3 gets hostb

action 1.4 cli command "enable"

action 1.5 cli command "config t"

action 1.6 cli command "ip access-list extended rite1_incoming"

action 1.7 cli command "no 10"

action 1.8 cli command "no 20"

action 1.9 cli command "10 permit ip host $hosta host $hostb"

action 2.0 cli command "20 permit ip host $hostb host $hosta"

action 2.1 cli command "ip access-list extended rite1_outgoing"

action 2.2 cli command "no 10"

action 2.3 cli command "no 20"

action 2.4 cli command "10 permit ip host $hosta host $hostb"

action 2.5 cli command "20 permit ip host $hostb host $hosta"

action 2.6 cli command "end"

action 2.7 cli command "show ip access-list | s rite1"

action 2.8 puts "$_cli_result"

action 2.9 puts ""

action 3.1 puts "-------------------------------------"

action 3.2 puts ""

action 3.3 puts "Use following packet_capture commands:"

action 3.4 puts " ritesh - show packet_capture"

action 3.5 puts " ritecl - clear packet_capture"

action 3.6 puts " ritestr - start packet_capture"

action 3.7 puts " ritestp - stop packet_capture"

action 3.8 puts ""

action 3.9 puts "-------------------------------------"

alias exec rite1 event manager run rite1

Router#rite1

Set HostA:

172.20.1.1

Set HostB:

20.1.1.1

Extended IP access list rite1_incoming

    10 permit ip host 172.20.1.1 host 20.1.1.1

    20 permit ip host 20.1.1.1 host 172.20.1.1

Extended IP access list rite1_outgoing

    10 permit ip host 172.20.1.1 host 20.1.1.1

    20 permit ip host 20.1.1.1 host 172.20.1.1

-------------------------------------

Use following packet_capture commands:

ritesh - show packet_capture

ritecl - clear packet_capture

ritestr - start packet_capture

ritestp - stop packet_capture

-------------------------------------

I use this for packet capturing with RITE on remote sites that do not warrant consistent samples. We get alerted when a specific top-talker is showing unusual high volumes of traffic and our techs are able to run the following script on the fly from mobile devices. The high-volume converstaion gets captured and we have another script that exports those onboard captures to centralized servers. The whole operation runs pretty great. The problem is that for some reason it eats a TON of process usage.

117852: Mar 28 23:03:54.197 DST: %SYS-1-CPURISINGTHRESHOLD: Threshold: Total CPU Utilization(Total/Intr): 72%/1%, Top 3 processes(Pid/Util):  199/71%, 49/0%, 81/0%

117865: Mar 28 23:04:09.128 DST: %SYS-1-CPUFALLINGTHRESHOLD: Threshold: Total CPU Utilization(Total/Intr) 1%/0%.

I"m assuming that process # 199 is dynamically created for this specific applet when it runs, as it does not seem to run on the routers at other times:

Router#show process cpu

....output omitted....

198           0           3          0  0.00%  0.00%  0.00%   0 EEM ED RPC

201       14371       99291        144  0.00%  0.00%  0.00%   0 DHCPD Receive

....output omitted....

For some reason, while the router is interacting with the user, waiting for input from the "action x.x get" commands, the processer is through the roof. Any ideas on how I could run this similar operation without taking up so much process overhead? I want to say that I could probably limit the resource usage of those specific processes maybe with ERM, but I'm currently not very familiar with ERM. Thanks for everyone's help.

7 Replies 7

yjdabear
Collaborator
Collaborator

I'm afraid you may have to convert the applet to a tcl script, in order to gain some form of resource control, specifically via the "nice #" option, which appears to be in the same boat as "queue_priority" discussed in this Q&A: https://supportforums.cisco.com/message/3030779#3030779

Joe Clarke
Hall of Fame Cisco Employee Hall of Fame Cisco Employee
Hall of Fame Cisco Employee

There appears to be a bug in the gets action which causes a CPU spike.  This does not happen if you use Tcl, though.  I converted your applet to a Tcl policy.  You should be able to see more reasonable gets behavior.

Joe,


This works great. Thanks again for all of your help.