EEM 2.1 - Event seems to work but then variable is not incremented

Unanswered Question
Feb 18th, 2008

The following configuration appears to be correct , but when it comes down to incrementing the value when crc errors occur, it does not. There might be some problem with syntax, however I can't seem to find out where it is:

event manager environment Atm0_Rx 0

event manager environment Atm0_Tx 0

event manager environment Atm0_CRC 0

event manager applet Atm0_Rx850kbps

event interface name ATM0 parameter receive_rate_bps entry-val 850000 entry-op ge entry-val-is-increment false poll-interval 300

action 1.0 counter name Atm0_Rx op inc value 1

event manager applet Atm0_Tx410kbps

event interface name ATM0 parameter transmit_rate_bps entry-val 410000 entry-op ge entry-val-is-increment false poll-interval 300

action 1.0 counter name Atm0_Tx op inc value 1

event manager applet Atm0_CRCin

event interface name ATM0 parameter input_errors_crc entry-val 10 entry-op ge entry-val-is-increment true poll-interval 900

action 1.0 counter name Atm0_CRC op inc value 1

action 1.1 syslog priority notifications msg "ATM0_CRC_Threshold"

!

event manager history size events 40

end

Can anyone help me out with this?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joe Clarke Mon, 02/18/2008 - 07:01

I just filed a bug for this (CSCsm70738). Basically, counters cannot be used across policies unless there is at least one policy registered to watch that counter using a counter event detector.

Your case is slightly different in that you're trying to use environment variables incorrectly. The counters are separate from environment variables. Instead of declaring three environment variables for your counters, you will need to create three more policies which register counter event detectors. Those policies will run when the counters reach a certain threshold. For example:

event manager applet watch_Atm0_Rx

event counter name Atm0_Rx entry-op ge entry-val 10 exit-op eq exit-val 0

action 1.0 syslog msg "Atm0_Rx reached threshold 10 times"

action 2.0 counter name Atm0_Rx op set value 0

luisaneves Wed, 02/20/2008 - 02:03

Dear jclarke, thank you for your explanation, but the thing is that we do not which to create more scripts on the eem, since it will consume more resources on the router. Whe are considering the possibility of sending directly to syslog the value of the counter in the message. Do you think that is possible, using the policies we already have and not creating new ones?

Apart from that, is there any way of checking these counters inside the eem, instead of seeing them in an internal or external syslog, using the history of the eem itself that can go up to 50 events registration to verify these values?

Thank you very much for your supoort.

Joe Clarke Wed, 02/20/2008 - 08:45

Sending the counter values in syslog will not work since the counters will be reset each time the applet is invoked due to the bug I mentioned. In order to make the counters persistent, you will need to have at least one policy registered to watch each of them.

As for checking the counters in EEM, the example policy I gave in my first post does this. It will watch the counter value, and trigger when it meets a certain value. Other than that, there is no way to see what the value is.

Yes, you could use the event history to see how many times a policy is invoked. It will not give you the counter value, but you can see the last 50 policies that ran.

Note: you convert these applet policies to TCL, and have them enter config mode and change the environment variable on each execution. This way you would have a visual indicator of the counter.

luisaneves Thu, 02/21/2008 - 02:23

Thank you very much for these solutions,you have been most diligent in answering my questions. We can close this as resolved, but anyway we would like to be informed of the bug fix in a future ios release, when it is solved by the engineering team. How can I do that?

Best Regards,

Luís A. Neves

Joe Clarke Thu, 02/21/2008 - 08:53

The bug is an enhancement request as EEM is currently working as designed. You should be able to track this bug on Cisco.com's Bug Toolkit to see when it is implemented.

Actions

This Discussion