Chapter 27. Event Manager

Event Manager is a feature in Arista switches that allows Bash scripts to be executed when certain system events occur. When I first wrote this chapter, I used EOS version 4.9.3, and the triggers were pretty limited. This update is using EOS 4.21.1F with Arista 7280SE-72 or 7280R switches on which some cool new options are included, most of which were added in 4.17.

So, what’s the benefit of such a feature? Suppose that you have a system that’s been spontaneously rebooting at odd times, and your executive management is too cheap to buy network management software. You could configure an event handler to send email (Chapter 22) to you (or the system guys, or whomever you’d like) any time the switch’s interface to that server goes down.

Description

Event handlers allow the creation of a trigger and an action. The trigger in my server example would be the interface on the switch going up or down. The action would be the email being sent. Additionally, we can set a delay so that a configured amount of time must pass after the trigger before the action is taken.

Note

If you’re convinced that you found a mistake because the name of the chapter is Event Manager but the previous paragraph says event handler, hold your errata, because this is a bit of an Aristacism. You see, the developers made a tool and named it after what it does: it handles events. Marketing then gets a hold of it and named it something that they like better: Event Manager. That’s why Event Manager has event handlers.

In the first edition of Arista Warrior, when EOS 4.9 was all the rage, only two types of triggers were supported. As of EOS v4.21, there are many more. They are:

on-boot
Triggered when the system boots. Note that this trigger also activates when exiting from event-handler configuration mode.
on-counters
Triggered when certain internal counter thresholds are exceeded.
on-intf
Triggered on certain interface-specific events. Note that this trigger also activates when exiting from event-handler configuration mode.
on-logging
Triggered when regex-matched entries appear in the system log.
on-maintenance
Triggered on maintenance operations.
on-startup-config
Triggered when the startup configuration changes.
vm-tracer
Triggered on VmTracer events.

Let’s take a look at each and see how they’re configured.

on-boot

The on-boot trigger has no other options.

on-counters

The on-counters trigger is a very powerful option that’s new as of version 4.16 and has significant additions in version 4.17. It can also be switch-dependent because it makes use of Application-Specific Integrated Circuit (ASIC) counters in the switch. This trigger can be a bit difficult to navigate, so let’s see if we can make it a bit more palatable.

First, the number of counters that can be used as triggers is enormous. To see them all, use the sho event-handler trigger counters command, but be warned: this will create a lot of output. How much output? Piping to the Bash wc command with the –l option, we can see how many lines of output are produced:

Arista#sho event-handler trigger counters | wc -l
7291

Sweet cats! 7,291 lines of output! Each of those lines includes a counter that we can use.

Note

The number and type of counters available are greatly dependent on the switch, the ASIC(s) in use on that switch, and possibly the version of EOS in use. For example, doing the same command on a 7280R running 4.21.1F results in 5,596 counters found.

Here’s just the first few:

Arista#sho event-handler trigger counters | more

The list of counters supported by the on-counters event handler

   Arad0.ActiveQueueCount
   Arad0.ActiveQueueCount.delta
   Arad0.AvailableSP0ReservedDataBuffers
   Arad0.AvailableSP0ReservedDataBuffers.delta
   Arad0.AvailableSP0ReservedPacketDescriptors
   Arad0.AvailableSP0ReservedPacketDescriptors.delta
   Arad0.AvailableSP1ReservedDataBuffers
   Arad0.AvailableSP1ReservedDataBuffers.delta
   Arad0.AvailableSP1ReservedPacketDescriptors
   Arad0.AvailableSP1ReservedPacketDescriptors.delta
   Arad0.BadRepliesCtr
   Arad0.BadRepliesCtr.delta
   Arad0.BdbDynSize
   Arad0.BdbDynSize.delta
   Arad0.Bfmc1CreditCtr
   Arad0.Bfmc1CreditCtr.delta
   Arad0.Bfmc2CreditCtr
--More--

This output is very different depending on the switch. On a 7280R, I get the following:

Student-20#sho event-handler trigger counters | more

The list of counters supported by the on-counters event handler

    Jericho0.Cgm0CgmMulticastDataBuffer
    Jericho0.Cgm0CgmMulticastDataBuffer.delta
    Jericho0.Cgm0CgmMulticastMaxDataBuffer
    Jericho0.Cgm0CgmMulticastMaxDataBuffer.delta
    Jericho0.Cgm0CgmMulticastMaxPacketDescriptor
    Jericho0.Cgm0CgmMulticastMaxPacketDescriptor.delta
    Jericho0.Cgm0CgmMulticastPacketDescriptorDropCnt
    Jericho0.Cgm0CgmMulticastPacketDescriptorDropCnt.delta
    Jericho0.Cgm0CgmMulticastReplicatedPacketDescriptor
    Jericho0.Cgm0CgmMulticastReplicatedPacketDescriptor.delta
    Jericho0.Cgm0CgmMulticastReplicationDropQueuePortCnt
    Jericho0.Cgm0CgmMulticastReplicationDropQueuePortCnt.delta
    Jericho0.Cgm0CgmMulticastSp0DataBuffer
    Jericho0.Cgm0CgmMulticastSp0DataBuffer.delta
--More--

There is a dizzying array of options, so how do we know which one to pick? Trial-and-error is my favorite blunt instrument, and back on my 7280SE, using it I discovered this:

Arista#sho event-handler trigger counters | grep idle
    tcollector.proc.stat.cpu.type=idle
    tcollector.proc.stat.cpu.type=idle.delta
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=0
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=0.delta
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=1
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=1.delta
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=2
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=2.delta
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=3
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=3.delta

I’ll show you how to use these counters in the configuration section later in this chapter.

on-intf

The on-intf trigger allows the following trigger types:

ip
Triggered on changes to the interface’s IP address assignment.
ip6
Triggered on changes to the interface’s IPV6 address assignment.
operstatus

Changes to the interface’s operational status (up, down, etc.).

If both the ip and operstatus triggers are specified, the trigger will be activated when either of them occurs. In other words, specifying them both equals the pseudo-code ip OR operstatus, and not ip AND operstatus.

To add even more power to this feature, the following variables are passed to Bash when an on-intf-triggered action is performed:

$INTF
The interface name of the interface specified in the trigger.
$OPERSTATE
The current (after the triggered event) operation status of the interface specified in the trigger.
$IP-PRIMARY
The current (after the triggered event) primary IP address of the interface specified in the trigger. Note that secondary IP addresses are not included.
$IP-SECONDARY
The current (after the triggered event) secondary IP addresses of the interface specified in the trigger. This data is returned as an array.
$IP6-PRIMARY
The current (after the triggered event) primary IPv6 address of the interface specified in the trigger. Note that secondary IP addresses are not included.
$IP6-SECONDARY
The current (after the triggered event) secondary IPv6 addresses of the interface specified in the trigger. This data is returned as an array.

on-logging

The on-logging trigger allows matching the system log against a regular expression (regex). You can set the regex through the regex subcommand, and the polling interval with the poll subcommand.

on-maintenance

The on-maintenance trigger allows you to perform an action when the switch either enters or exits maintenance mode and can be further refined to maintenance mode in Border Gateway Protocol (BGP), on an interface, or for a unit.

on-startup-config

The on-startup-config trigger is used to perform an action when the write memory (or copy run start) command is used. Note that it does not trigger if you manually edit the startup-config.

Actions are Bash commands of any type. If you’d like your action to perform more than one command, write a script in Bash and then reference the script in the action. Many people look at this at first and think that it’s a severe limitation, but it’s absolutely not. Consider this Bash script:

#!/bin/bash
# Shuts down an interface input from CLI

/usr/bin/Cli -c "
 enable
 configure
 interface $1
  shut "

This is a Bash script using Cli (which is now the same as FastCli, remember) that issues a series of command-line interface (CLI) commands. The $1 is a token that means we can pass a value to the script. Here’s how it works:

Arista(config-if-Et1)#sho int status | grep "Et1 "
Et1             connected  in Po1   a-full a-1G   1000BASE-T
Arista(config-if-Et1)#bash /mnt/flash/ShutInt.sh e1
Arista(config-if-Et1)#sho int status | grep "Et1 "
Et1             disabled   in Po1   auto   auto   1000BASE-T

We can absolutely use something like this as an action in event handler, though the variable $1 would likely be replaced with $INTF.

Configuring Event Handlers

Configuring event handlers is a pretty simple affair. The most difficult part would be writing any scripts that you’d like to call and, if you’re using the on-counter trigger, determining which counter you’d like to use. Let’s take a look and see some real examples.

To configure an event handler, enter the event-handler configuration mode by using the event-handler event-name command. The event name is anything you’d like it to be, but I urge you to make the name obvious and related to the event trigger in some way. Here, I configure a simple event-handler called Int-E1-UpDown:

Arista(config)#event-handler Int-E1-UpDown
Arista(config-handler-Int-e10-updown)#

This drops me into event-handler configuration mode. From there, I can do a bunch of stuff (I love the word stuff, don’t you?), as evidenced by the following:

Arista(config-handler-Int-E1-UpDown)#?
  action        Define event-handler action
  asynchronous  Set the action to be non-blocking
  delay         Configure event-handler delay
  threshold     Threshold time window where a number of events should happen
  timeout       Set the expected time the action should finish in
  trigger       Configure event trigger condition
  ----------------------------------------
  comment       Up to 240 characters, comment for this mode
  default       Set a command to its defaults
  exit          Exit from Event handler configuration mode
  help          Description of the interactive help system
  no            Negate a command or set its defaults
  show          Show running system information
  !!            Append to comment

Adding comments to parts of the configuration is a wonderful Arista feature that I encourage you to make use of. Let’s add a comment to our event by entering the command comment alone on a line. This drops you into comment mode, in which you can type a whole bunch of stuff (yeah! more stuff!) across multiple lines. Enter EOF alone on a line to exit this mode:

Arista(config-handler-Int-E1-UpDown)#comment
Enter TEXT message. Type 'EOF' on its own line to end.
Trigger for Int-e10 status change
Added November 2018 by GAD
EOF
Arista(config-handler-Int-E1-UpDown)#

Now let’s define the trigger. I’d like my action to take place any time the interface’s status changes, so I use trigger on-intf interface-name operstatus:

Arista(config-handler-Int-E1-UpDown)#trigger on-intf e1 operstatus

With my trigger set, now I need to configure the action to be performed on the trigger being, well, triggered. This is done with the action bash bash-command command. The command I’m going to use is email –s “Int $INTF is now $OPERSTATE”. This will send an email with the subject line of Int Ethernet10 is now linkdown when the interface goes down, and Int Ethernet10 is now linkup when it comes up:

Arista(config-ha[…]-UpDown)#action bash email -s "Int $INTF is now $OPERSTATE"
Warning

For this example to work, you must configure email. See Chapter 22 for instructions on how to accomplish this. Kudos if you’ve read that chapter and can see what’s wrong already.

Just for fun, I include a delay of five seconds:

Arista(config-handler-Int-E1-UpDown)#delay 5

While still in event-handler configuration mode, the event is not yet active. To enable it, exit the mode:

Arista(config-handler-Int-e10-updown)#exit
Arista(config)#

My configured event handler looks like this in the running-config:

event-handler Int-E1-UpDown
   !! Trigger for Int-e10 status change
   !! Added November 2014 by GAD
   trigger on-intf Ethernet1 operstatus
   action bash email -s "Int $INTF is now $OPERSTATE"
   delay 5

That’s all great, but let’s see what happens when the event is actually triggered. After walking up and pulling the cable from interface e10, the following lines appeared in the switch’s log:

Arista#sho log last 5 min
Nov 26 00:48:14 Arista Cli: %SYS-5-CONFIG_I: Configured from console by admin
 on vty7 (10.0.0.100
Nov 26 00:48:22 Arista Cli: %SYS-5-CONFIG_E: Enter configuration mode from
 console by admin on vty7
(10.0.0.100)
Nov 26 00:49:08 Arista EventMgr: %SYS-6-EVENT_TRIGGERED: Event
handler Int-E1-UpDown was activated
Nov 26 00:49:09 Arista EventMgr:
%SYS-5-EVENT_ACTION_FAILED: Eventhandler action Int-E1-UpDown did not complete
 with exit code 0:Action returned with exit code 2

Well, that doesn’t look good!

Looking at the configuration, I’m sure many of you saw my earlier mistake, but I did it on purpose (seriously!) to show that incorrect commands will be freely accepted by the event-handler command.

Let’s take a look at the event handler with the show event-handler command to see where I messed up:

Arista#sho event-handler Int-E1-UpDown
Event-handler Int-E1-UpDown
Trigger: on-intf Ethernet1 on operstatus delay 5 seconds
Threshold Time Window: 0 Seconds, Event Count: 1 times
Action: email -s "Int $INTF is now $OPERSTATE"
Action expected to finish in less than 10 seconds
Last Trigger Detection Time: 2 minutes 53 seconds ago
Total Trigger Detections: 1
Last Trigger Activation Time: 2 minutes 53 seconds ago
Total Trigger Activations: 1
Last Action Time: 2 minutes 48 seconds ago
Total Actions: 1

This shows some nice information regarding my configured event, including how long ago it was triggered and how many times it’s been triggered. What we’re looking for, however, is why it doesn’t work. That answer is in the action command string. The email command I referenced requires a destination email address to work, but I didn’t give it one. To fix that, I need to go back into event-handler configuration mode and reenter the action command:

Arista#conf
Arista(config)#event-handler Int-E1-UpDown
Arista(config-handler-Int-E1-UpDown)#action bash email -s "Int $INTD is now
 $OPERSTATE" [email protected]
Arista(config-handler-Int-E1-UpDown)#exit

Now, I go plug in my cable into interface e10 and see what happens:

Arista#sho log last 1 min
Nov 26 00:53:03 Arista EventMgr: %SYS-6-EVENT_TRIGGERED: Event
handler Int-E1-UpDown was activated

Sure enough, five seconds after insertion, I received the following email:

Date: Fri, 25 Nov 2016 19:13:29
From: [email protected]
To: [email protected]
Subject: Int Ethernet1 is now linkup

Nice! But what about those counters I talked about? Let’s set an event handler that triggers on CPU utilization. First, we set up the base event handler:

Arista(config)#event-handler CPU-Util
Arista(config-handler-CPU-Util)#trigger on-counters
Arista(config-handler-CPU-Util-counters)#

Now, we need to choose a counter. Remember the way we found idle counters? Let’s use that information now:

Arista#sho event-handler trigger counters | grep idle
    tcollector.proc.stat.cpu.type=idle
    tcollector.proc.stat.cpu.type=idle.delta
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=0
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=0.delta
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=1
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=1.delta
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=2
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=2.delta
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=3
    tcollector.proc.stat.cpu.percpu.type=idle,cpu=3.delta

We use that first one and make an event handler based on it. We also add some new commands because CPU on these systems can be very spiky, which is perfectly OK.

In this example, we check one of those counters and trigger only if it reports a value of less than 20 twice within 20 seconds while polling every five seconds (which is kind of a useless thing to report, but it’s easy to trigger, which is why I used it).

Arista(config)#event-handler CPU-Util
Arista(config-handler-CPU-Util)#trigger on-counters
Arista(config-handler-CPU-Util-counters)#poll interval 5
Arista(config-handler-CPU-Util-counters)#condition
 tcollector.proc.stat.cpu.type=idle < 20
Arista(config-handler-CPU-Util-counters)#action bash wall "Idle < 20%!"
Arista(config-handler-CPU-Util-counters)#threshold 20 count 2
Arista(config-handler-CPU-Util)#exit

Here’s the result that popped up on my session after a short while:

Arista(config)#
Broadcast message from root@Arista (Tue Jan 15 20:11:44 2019):

Idle < 20%!

Arista(config)#

That’s kind of nonintuitive, so here’s another way to do it:

Arista(config)#event-handler CPU-Util
Arista(config-handler-CPU-Util)#trigger on-counters
Arista(config-handler-CPU-Util-counters)#poll interval 5
Arista(config-handler-CPU-Util-counters)#condition bashCmd."IDLE=$((100-$(vmstat 1
 2 | tail -n 1 | awk '{ print $15 }'))); echo $IDLE" > 80
Arista(config-handler-CPU-Util)#action bash wall "CPU > 80%"
Arista(config-handler-CPU-Util)#exit
Arista(config)#
Broadcast message from root@Arista (Sat Nov 26 02:57:34 2016):

CPU > 80%

Arista(config)#

Note that the action is triggered as soon as I typed exit, which unfortunately seems to be the way this feature is coded.

OK, so I’m not sure that’s exactly intuitive, either, but it works, so now you have two options that work if you’re inclined to build a CPU threshold alarm using event handler.

Now let’s try to kick the CPU up a bit with my own utility called corecrusher. Note that this is not an Arista utility, and it is definitely not something you should do on a production switch.

Note

You can download corecrusher from my GitHub page along with a bunch of other interesting (and potentially dangerous) Arista-related stuff.

The command will crush a number of CPU cores at 100% for the number of seconds listed. In this example, I consume three CPU cores at 100% for 20 seconds. Note that I’ve configured event handler to poll the CPU percentage every five seconds. Let’s see what happens.

Arista#bash /home/admin/corecrusher 3 20
To stop corecrusher before the configured time, use the following command:
corecrusher stop
Crushing 3 core(s) for 20 second(s)
Arista#
Broadcast message from root@Arista (Sat Nov 26 03:03:25 2016):
CPU > 80%
Removing stat file...
Killing corecrushers...
Killed corecrusher(29523) with signal 15
Killed corecrusher(29524) with signal 15
Killed corecrusher(29525) with signal 15
Killed corecrusher(29526) with signal 15

It worked!

Now, this is not the most efficient way of monitoring the CPU (CloudVision for the win!), and honestly given the way that Arista switches (and Linux systems) operate, high CPU is not something that is generally a concern, but I made a thing, and that makes me happy.

All in all, setting up and using an event handler is pretty simple, yet this can be a pretty powerful tool.

How about one more example? I used to work with a guy I nicknamed Cowboy Bob the Network Operator from Hell. One of the reasons he earned such a colorful nickname was that he regularly did things like this:

Arista>
Arista>en
Arista#wri
Copy completed successfully.
Arista#conf
Arista(config)#wri
Copy completed successfully.
Arista(config)#int e5
Arista(config-if-Et5)#wri
Copy completed successfully.
Arista(config-if-Et5)#desc I like chaos
Arista(config-if-Et5)#wri
Copy completed successfully.
Arista(config-if-Et5)#

Looking over his shoulder while he did this one day I had to yell, “Stop it!” after which he gave me the “I don’t want to lose any of my changes” excuse. I had to explain to him that his continued writes after each command meant that I couldn’t easily back out of his changes. People can be difficult to change, so how might I use event handler to manage the problem? By using the on-startup-config trigger!

The on-startup-config trigger is triggered when the startup-config changes, but that’s actually just mostly true. You see, if you were to drop into Bash and edit the startup-config with your favorite editor, that would not trigger event handler. What will trigger this event handler is any system command that changes the startup-config such as write mem, copy run start, and so-on. Here’s an example of this trigger in action:

Arista(config)#event-handler CowboyBob
Arista(config-handler-CowboyBob)#trigger on-startup-config
Arista(config-handler-CowboyBob)#action bash /mnt/flash/CowboyBob.sh

Now that we have the EOS commands in place, let’s see what’s in the Bash script:

[admin@Arista flash]$ more CowboyBob.sh
#!/bin/bash

NEWNAME="startup-config_$(date +'%Y-%m-%d_%H-%M-%S')"
cp /mnt/flash/startup-config /mnt/flash/$NEWNAME

Running this script results in making a copy of the startup-config with a timestamp following the filename. Here’s an example file output from manually running the script:

[admin@Arista flash]$ ./CowboyBob.sh
[[admin@Arista flash]$ ls -al start*
-rwxrwx--- 1 root eosadmin 3162 Jan 15 20:24 startup-config
-rwxrwx--- 1 root eosadmin 3162 Jan 15 20:38 startup-config_2019-01-15_20-38-16

Now let’s see what happens when I follow CowboyBob’s example with the event handler enabled!

Arista>
Arista>en
Arista#wri
Copy completed successfully.
Arista#conf
Arista(config)#wri
int e5Copy completed successfully.
Arista(config)#int e5
Arista(config-if-Et5)#wri
Copy completed successfully.
Arista(config-if-Et5)#desc I like chaos
Arista(config-if-Et5)#wri
Copy completed successfully.
Arista(config-if-Et5)#^z
Arista#bash ls -al /mnt/flash/start*
-rwxrwx--- 1 root eosadmin 3256 Jan 15 20:41 /mnt/fla[…]ig
-rwxrwx--- 1 root eosadmin 3162 Jan 15 20:38 /mnt/fla[…]ig_2019-01-15_20-38-16
-rwxrwx--- 1 root eosadmin 3162 Jan 15 20:41 /mnt/fla[…]ig_2019-01-15_20-41-27
-rwxrwx--- 1 root eosadmin 3256 Jan 15 20:41 /mnt/fla[…]ig_2019-01-15_20-41-50

Wait a minute: I issued four wri commands but only added two additional files. Why? Because of the nature of this feature and the fact that there is an inherent delay in processing the triggers could not keep up with my cowboy-speed flurry of writes. To remedy this, I’m going to add a delay 0 to my event handler because there is a built-in delay:

Arista(config)#event-handler CowboyBob
Arista(config-handler-CowboyBob)#delay 0
Arista(config-handler-CowboyBob)#exi
Arista(config)#

Let’s try again:

Arista>
Arista>en
Arista#wri
Copy completed successfully.
Arista#conf
Arista(config)#wri
int e5Copy completed successfully.
Arista(config)#int e5
Arista(config-if-Et5)#wri
Copy completed successfully.
Arista(config-if-Et5)#desc I like chaos
Arista(config-if-Et5)#wri
Copy completed successfully.
Arista(config-if-Et5)#

Remember, there were four timestamped configuration files before, and we just issued an additional four write commands, so there should be eight files timestamped total now:

Arista(config-if-Et5)#bash ls -al /mnt/flash/start*
-rwxrwx--- 1 root eosadmin 3267 Jan 15 20:45 /mnt/flash/startup-config
-rwxrwx--- 1 root eosadmin 3162 Jan 15 20:38 /mnt/fla[…]ig_2019-01-15_20-38-16
-rwxrwx--- 1 root eosadmin 3162 Jan 15 20:41 /mnt/fla[…]ig_2019-01-15_20-41-27
-rwxrwx--- 1 root eosadmin 3256 Jan 15 20:41 /mnt/fla[…]ig_2019-01-15_20-41-50
-rwxrwx--- 1 root eosadmin 3256 Jan 15 20:45 /mnt/fla[…]ig_2019-01-15_20-45-08
-rwxrwx--- 1 root eosadmin 3267 Jan 15 20:45 /mnt/fla[…]ig_2019-01-15_20-45-22
-rwxrwx--- 1 root eosadmin 3267 Jan 15 20:45 /mnt/fla[…]ig_2019-01-15_20-45-31
-rwxrwx--- 1 root eosadmin 3267 Jan 15 20:45 /mnt/fla[…]ig_2019-01-15_20-45-39
-rwxrwx--- 1 root eosadmin 3267 Jan 15 20:45 /mnt/fla[…]ig_2019-01-15_20-45-49

Success!

The rapid proliferation of files does raise an important point, which is that such a script will happily fill up the flash drive, especially given the nature of Cowboy Bob and his maniacal configuration writing. How might you deal with that? You could write some logic similar to Linux’s logrotate, which would save only the last 10 (or 50 or whatever) files. You could save the file somewhere other than flash, but remember that the filesystem on an Arista switch will go away after a reboot. You could mount a Network File System (NFS) drive or you could copy to a remote location using the Secure Copy Protocol (SCP) or use TFTP or a pile of other options, because if there’s one thing Arista gives us a lot of, it’s options.

Also, I’d probably consider something like Authentication, Authorization, and Accounting (AAA) logging to be a better solution to the Cowboy Bob problem, but my simple script does produce a usable configuration after every iteration where AAA logging does not.

Showing the Event Handler Status

Showing the status of your event handlers is as simple as using the show event-handler command:

Arista#sho event-handler
Event-handler DropCountersHandler (BUILT-IN)
Trigger: on-counters delay 0 seconds
  Polling Interval: 60 seconds
  Condition: bashCmd."DropCounterMonitor.py" > 0
Threshold Time Window: 0 Seconds, Event Count: 1 times
Action: DropCounterLog.py -l
Action expected to finish in less than 20 seconds
Total Polls: 7230
Last Trigger Detection Time: 5 days 29 minutes ago
Total Trigger Detections: 1
Last Trigger Activation Time: 5 days 29 minutes ago
Total Trigger Activations: 1
Last Action Time: Never
Total Actions: 1

Event-handler CPU-Util
Trigger: on-counters delay 20 seconds
  Polling Interval: 5 seconds
  Condition: bashCmd."IDLE=$((100-$(vmstat 1 2 | tail -n 1 | awk '{ print $15
 }'))); echo $IDLE" > 80
Threshold Time Window: 0 Seconds, Event Count: 1 times
Action: wall "CPU > 80%"
Action expected to finish in less than 10 seconds
Total Polls: 1
Last Trigger Detection Time: 3 seconds ago
Total Trigger Detections: 1
Last Trigger Activation Time: 3 seconds ago
Total Trigger Activations: 1
Last Action Time: Never
Total Actions: 0

Event-handler Int-E1-UpDown
Trigger: None
Threshold Time Window: 0 Seconds, Event Count: 1 times
Action: email -s "Int $INTD is now $OPERSTATE" [email protected]
Action expected to finish in less than 10 seconds
Last Trigger Detection Time: Never
Total Trigger Detections: 0
Last Trigger Activation Time: Never
Total Trigger Activations: 0
Last Action Time: Never
Total Actions: 0

Event-handler CowboyBob
Trigger: on-startup-config delay 0 seconds
Threshold Time Window: 0 Seconds, Event Count: 1 times
Action: /mnt/flash/CowboyBob.sh
Action expected to finish in less than 10 seconds
Last Trigger Detection Time: 9 minutes 18 seconds ago
Total Trigger Detections: 5
Last Trigger Activation Time: 9 minutes 18 seconds ago
Total Trigger Activations: 5
Last Action Time: 9 minutes 18 seconds ago
Total Actions: 5

You can also show individual event handlers by specifying an individual name. Let’s do that now with the first one from the preceding output because I didn’t enter that one:

Arista#sho event-handler DropCountersHandler
Event-handler DropCountersHandler (BUILT-IN)
Trigger: on-counters delay 0 seconds
  Polling Interval: 60 seconds
  Condition: bashCmd."DropCounterMonitor.py" > 0
Threshold Time Window: 0 Seconds, Event Count: 1 times
Action: DropCounterLog.py -l
Action expected to finish in less than 20 seconds
Total Polls: 7232
Last Trigger Detection Time: 5 days 31 minutes ago
Total Trigger Detections: 1
Last Trigger Activation Time: 5 days 31 minutes ago
Total Trigger Activations: 1
Last Action Time: Never
Total Actions: 1

Apparently, my switch has a built-in event handler, so that’s nice. There’s really not much else to see and no other useful show commands to talk about, but these do give everything you need to know about what’s going on..

Conclusion

Event handlers are a great way to automate tasks based on triggered events on your Arista switches. I’ve actually used this feature to great effect in both my labs and the real world. I encourage you to play around with it and see what it can do for you in your environment.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.224.70.238