Cisco 1841/871 crash EEM scripting 15.1(1)T

Answered Question
May 20th, 2010

We have been testing 15.1.1T on a couple of lab Cisco 1841 and Cisco 871 devices.



On the devices we are using EEM to automate the failover/failback process for a cellular modem attached to f3 on the 871 or f0/1 on the 1841. One of the EEM applets we use fires from a cron timer event that occurs every 10 minutes on the router.


IOS revision 12.4(22)T we had no problems with using the cron-timer triggered applet (every 10 minutes between 7am to 10pm), except for the fact that every command issued by EEM required AAA authentication. The EEM applet is causing our routers to saturate our Cisco ACS servers (we use 700+ routers in the field, all exectuing this EEM script) with single-connect requests. We will refer to the cron-timer executed applet as 'Maintenance' from here on out.


As of 15.1(1)T the addition to bypass the AAA authentication process became available. This was a huge speed increase to our EEM applets, specifically the Maintenance applet. I will include the applet for clairity.


event manager applet Maintenance authorization bypass
event timer cron name 10min cron-entry "*/10 7-21 * * *" maxrun 30
action 001 cli command "en"
action 002 cli command "show ip route | section B\*[ ]+0\.0\.0\.0"
action 003 regexp "^B\*.([ ]+)(0\.)+0" "$_cli_result"
action 004 set bgpstate "$_regexp_result"
action 005 cli command "show ip route | section S[ ]+208\.38\.154\.8"
action 006 regexp "^S([ ]+)208\.38\.154\.8" "$_cli_result"
action 007 set wireless "$_regexp_result"
action 008 track read 1
action 009 set track1 "$_track_state"

action 010 if $wireless eq 0
action 011       if $bgpstate eq 0
action 012             cli command "conf t"
action 013             cli command "int fa0/1"
action 014             cli command "no shut"
action 015             cli command "int tun201"
action 016             cli command "no shut"
action 017             cli command "int lo201"
action 018             cli command "no shut"
action 019             if $track1 eq up
action 020                   exit
action 021                   else
action 022                   cli command "conf t"
action 023                   cli command "int s0/0/0"
action 024                   cli command "no shut"
action 025             end
action 026             cli command "end"
action 027             cli command "exit"
action 028       else
action 029             exit
action 030            end
action 031 else
action 032       if $bgpstate eq 1
action 033             cli command "conf t"

action 034             cli command "int fa0/1"
action 035             cli command "shut"
action 036             cli command "int tun201"
action 037             cli command "shut"
action 038             cli command "int lo201"
action 039             cli command "shut"
action 040             cli command "end"
action 041             cli command "exit"
action 042      else
action 043             if $track1 eq up
action 044                   exit
action 045             else
action 046                   cli command "conf t"
action 047                   cli command "int s0/0/0"
action 048                   cli command "no shut"
action 049             end

action 050             cli command "end"
action 051             cli command "exit"
action 052             exit
action 053       end
action 054 end



This script is designed to look for a couple of routes in the IP routing table, and populate two variables (bgpstate and wireless) with the regular expression matching result of the show ip route commands. It uses track 1 to determine the up/down status of Serial0/0/0 which is the primary T1 interface for WAN services on the router. The wireless is "up/1" if the static route to 208.38.154.8 is present in the show ip route output (only when f0/1 is up in this case). The T1 is "up/1" if the default route passed to the IP routing table is present in the show ip route output.


Before the upgrade to 15.1(1)T these scripts ran without issue, and we had no errors. Now after the upgrade, anytime this script fires and the show ip route match for the wireless variable is 1 instead of zero, it begins to run through the else condition starting at action 031, and during the second execution of the script every 10 minutes (I still have not figured out how to force the cron-timer to fire only ONCE per minute, instead of at the beginning and end of the minute), the router will generate spurious memory errors, and sometimes crash or reboot.


This all began with 15.1(1)T, and I have not seen any caveats or other entries that could possibly point to the cause of this problem. Any ideas?


I am also attaching a crash file from one of the routers like this one so you can see what I mean.


All of these devices are running the advipservices k9 version of this IOS.


Thanks for your time.

Correct Answer by Joe Clarke about 6 years 9 months ago

The problem with cron events running twice in the same minute is bug CSCsz12460 which will be fixed in EEM 3.2 in 15.1(3)T.


The crash you're seeing doesn't appear to be related to EEM at all.  It looks like a problem with single-connection TACACS+.  The bug appears to be CSCtg40901 which has not yet been fixed in 15.1T.


A workaround was suggested to use multiple-connection TACACS+.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Joe Clarke Thu, 05/20/2010 - 13:06

The problem with cron events running twice in the same minute is bug CSCsz12460 which will be fixed in EEM 3.2 in 15.1(3)T.


The crash you're seeing doesn't appear to be related to EEM at all.  It looks like a problem with single-connection TACACS+.  The bug appears to be CSCtg40901 which has not yet been fixed in 15.1T.


A workaround was suggested to use multiple-connection TACACS+.

lyranvolcrane Thu, 05/20/2010 - 13:12

If I understood authorzation bypass correctly though, when the EEM script attempts to use a cli command, it doesn't attempt to use AAA at all, doesn't it?

Joe Clarke Thu, 05/20/2010 - 13:23

Not exactly.  The AAA subsystem is still involved (i.e. an AAA user is created).  However, if bypass is enabled, then the actual authorization step is not done.  The CLI command is just allowed to run.

lyranvolcrane Fri, 05/21/2010 - 10:19

Much appreciated for the extra info. Thanks clairfying my muddy understanding of the AAA system

Actions

This Discussion

Related Content