This topic is to discuss the following lesson:
This shows how to send one alert when the ping fails. But how would configure to send recurring alerts - for example every hour while the ping is failing ?
Hello Charles
The EEM scripting language is quite detailed and powerful and is able to implement various configurations including periodically sending an update of the status of a specific value. This is done using the Watchdog periodic timer event. You can find out more about this at this Cisco link:
For a general command reference of EEM you can see the following link:
I hope this has been helpful!
Laz
1 Like
Thanks for the replay. I discovered from reading the documentation and opening a Cisco TAC ticket that i cannot send multiple alerts on the back of one snmp trap. I will check with Solarwinds our monitoring system if there is a way to do this.
From Cisco TAC 
there is no way to generate more than alert for the same event, because the alert is already triggered by the syslog, and if only one sysreport generated this will send only one alert,
1 Like
Hello Charles
That’s great info, thanks for sharing your experience. It is appreciated!
Laz
Hello,
I am using EEM to track an IP SLA and in case it’s DOWN, I would want to send an SNMP-TRAP to NMS. IP SLA and Track works perfectly, however, the SNMP traps are not being sent. Please review my code and advise if I am missing something. Thanks.
rt-1#debug snmp packets
SNMP packet debugging is on
rt-1#sho run | s event
snmp-server enable traps event-manager
event manager applet TRACK_IP_DOWN
event track 1 state down
action 1.0 syslog msg "IP SLA 100 is down"
action 2.0 mail server "smtp-1.local" to "networkadmins@local" from "no-reply@local" subject "IP SLA 100 is down" body "IP SLA 100 is not receiving ICMP echo replies anymore"
action 3.0 snmp-trap strdata "SNMP: IP SLA 100 is not receiving ICMP echo replies anymore"
rt-1#sho run | s snmp
snmp-server community test RO
snmp-server trap-source GigabitEthernet0/1
snmp-server location GNS3 Lab
snmp-server enable traps event-manager
snmp-server host 172.30.1.10 informs version 2c test
snmp-server host 172.30.1.10 version 2c testHello Networkeh
At first glance, there doesn’t seem to be a problem with your configuration. Reviewing the command reference of the action snmp-trap command in the following document doesn’t seem to indicate any problems with the specific config.
However you do state that
How have you determined this? Verify that the track 1 state is indeed being detected and is indeed changing its behaviour based on the desired functionality.
Once you’ve checked this, check to see if other SNMP traps are being sent to the SNMP server, ones that are not triggered by an EEM script to see that the server and client are indeed configured correctly. Check those out and get back to us with your results.
I hope this has been helpful!
Laz
1 Like
Hello Laz for comment.
I finally found the problem.
EEM Action 3.0 never taken because it failed at action 2.0!!
Regards,
Networkeh
1 Like
Hello All,
We are probing/tracking an IP address with IP SLA and in case the track goes down, EEM sends an SNMP trap. So far so nice. Now, what I want to gather is to send somehow the RTT for each ping which our IP SLA performs to the NMS.
At the end, we should when track goes down receive a trap (which works perfectly) as well as storing all RTTs at the frequency of IP SLA (which I don’t know hot to gather the IP SLA rtt output)
Any idea please?
--
Regards,
Networkeh
Hi Networkeh,
I think this will be difficult to retrieve from the show ip sla output. Some ideas that come to mind:
- Monitor from the NMS. It seems LibreNMS supports it. Solarwinds and PRTG have something too.
- Use SNMP to fetch IP SLA statistics.
- Use netflow to monitor your IP SLA traffic.
- Use EEM to run something like
show ip sla statistics | redirect. This doesn’t give you a “per ping” output.
Rene
3 Likes
Thanks Rene,
I liked the 3rd option (Netflow)
1 Like
Hello sir, I am trying to simulate a voip trafic between the core switch and cluster that host PBX server. I am unable to get a successful return code. I understand the part i do not have an IP sla responder set up, but i think IP SLA should still be able to work. Do you another scenario this may work? can i set it up between by c9200 and SRX firewall or GPON interface.
Here is my config
---------------------------- ip-sla 1
cisco-stack1(config-ip-sla)#udp-jitter 10.20.28.11 49152 codec g711alaw
cisco-stack1(config-ip-sla-jitter)#frequency ?
<1-604800> Frequency in seconds
cisco-stack1(config-ip-sla-jitter)#frequency 60
cisco-stack1(config-ip-sla-jitter)#tag VOIP
cisco-stack1(config-ip-sla-jitter)#tos 184
cisco-stack1(config-ip-sla-jitter)#exit
cisco-stack1(config)#ip sla schedule 1 start-time now life forever
cisco-stack1(config)#exit
cisco-stack1#show ip sla statistics 1
IPSLAs Latest Operation Statistics
What would you recommend?
Hello Temitope
If you want to measure jitter using the IP SLA feature, then you must use an IP SLA responder, otherwise you will not get any response from the other end. There is no other way to implement the IP SLA jitter analyzer. If you want to measure jitter over a particular link, there are other tools that you can use. These include using monitoring software such as Solarwinds, or other tools such as Etherate, which is developed on Github. Alternatively, you can configure a Raspberry Pi as an SLA rsponder, so you can physically connect it to the far end and achieve your SLA measurements. Take a look at the following post for more details about that…
I hope this has been helpful!
Laz
I am a bit confused about sync and skip. Can someone provide some clarification?
Hello Justin
The sync and skip keywords are part of the event cli command.
The sync yes keywords will cause the EEM script and the CLI command to be run simultaneously. In the event that you use this, the skip keyword is not used.
The sync no keywords will cause the EEM script and the CLI command to be run sequentially, the script first, and then the CLI command. When this is used, you must then specify the skip keyword as well.
If you use skip yes, then the CLI command is skipped completely and is not run. If you choose skip no, the CLI command is run right after the EEM script.
An example will help in understanding this.
event manager applet NoReload
event cli pattern "reload" sync no skip yes
action 1.0 syslog priority errors msg "Cannot reload this router"
The sync no option tells the script to run before the CLI command is executed. This means that this applet is executed before the actual reload CLI command is executed. This gives you the opportunity to choose what to do after the applet is run. Since skip yes is indicated, the reload CLI command is skipped completely and is replaced by the actions of the script.
Take a look at this example:
event manager applet NoReload
event cli pattern "reload" sync no skip no
action 1.0 syslog priority errors msg "The router is rebooting"
In this case, the script will run, displaying the message, but the CLI command will also be run right after that, and the router will reload.
In this case:
event manager applet NoReload
event cli pattern "reload" sync yes
action 1.0 syslog priority errors msg "The router is rebooting"
the reload process and the script run simultaneously. So you may or may not see the message being displayed. The router will reload.
I hope this has been helpful!
Laz
1 Like