Event Manager on-logging handler

Introduction The EOS Event Manager feature, introduced in 4.17.0F,  provides the ability to specify a condition and an action to be carried out when that condition is detected. It is a flexible and configurable way to automate the reaction to conditions without the need for a system operator to observe and apply the desired actions manually. The on-logging event handler extension to the Event Manager provides a framework to detect text strings in Syslog messages. When the condition is met, an action specified by the user will be carried out. The regular expression pattern matching is done on the messages in...
Continue reading →

Setting up sys log levels

I have our 7150s set to send logs to our sys log server but am having trouble finding documentation on how to set the levels we want. When I go to “logging level ?”, I see a long list of facilities and then under “logging level [facility] ?” I see the different levels. Is it possible to select multiple facilities and then their levels? Where is some good documentation on this? Thanks,  

Using AAA to log all commands from users on Arista EOS

Introduction Some users of Arista Networks EOS may want to log all commands executed on a switch. This article explains how to use AAA without TACACS or RADIUS to provide accounting of all commands to the system log. The log can then be sent off to a syslog server or even sent to Splunk using the Arista EOS splunk extension. For more information about the Splunk app for Arista EOS click here. Setup First, it is important to create a user account for each switch administrator. Without a separate account for each administrator it will be impossible to retain accurate...
Continue reading →

System and Process Logging

In addition to the log provided by the ‘show logging’ CLI command, EOS, being a linux based OS, provides users with the ability to access the underlying Linux system logs as well as the individual EOS agent process logs for multiple agent instances (due to reconfiguration or in-service stateful repair). These logs can be accessed via invoking the bash Linux shell directly via the EOS CLI as follows: Arista#bash sudo tail /var/log/messages Feb 17 20:01:01 Arista CROND[32288]: (root) CMD (run-parts /etc/cron.hourly) Feb 17 20:01:01 Arista run-parts(/etc/cron.hourly)[32288]: starting 0anacron Feb 17 20:01:01 Arista run-parts(/etc/cron.hourly)[32297]: finished 0anacron Feb 17 20:01:01 Arista run-parts(/etc/cron.hourly)[32288]:...
Continue reading →

Collecting logs for Arista TAC cases using logGrab

logGrab is a simple bash script that builds a time/date stamped archive containing a number of log items commonly requested when raising a TAC case. It is designed to simplify the process of collecting data from multiple sources within EOS and packing them into a single file for easy upload. The script can be easily extended/adapted and may be integrated easily with other EOS features such as the CLI scheduler and Advanced Event Manager. #!/bin/bash # logGrab - Automatic Log Collector v0.3 LOGNAME=logGrab-$HOSTNAME-$(date +%Y-%m-%d.%H%M%S) mkdir /mnt/flash/$LOGNAME cd /mnt/flash/$LOGNAME ls -alR /persist/sys > persist-sys-contents ls -alR /mnt/flash > flash-contents ls -alR...
Continue reading →

Restarting EOS agents

Objective This article shows an experiment which demonstrates what happens when an EOS agent is killed (either voluntarily, or as a result of a failure). Preparation (optional) In the frame of this article, and for testing purpose only, we take few preparation steps that are not absolutely necessary in a production environment: 1) Clear the logs to improve visibility (less noise in the logs) Arista#clear logging 2) Configure high resolution logging timestamps Arista (config)#logging format timestamp high-resolution Killing an agent 1) Access the bash shell Arista#bash 2) Select a process and find its PID (Process ID) [admin@Arista ~]$ ps –ef |...
Continue reading →

Logging to USB or SSD

All Arista switches offer support for USB flash drives and many models support the addition of an internal SSD. Either flash can be used to store log files, TCPDump/sFlow captures, configuration history and etcetera. This particular post describes three unique methods for logging to USB or SSD. Note: The USB flash is mounted to /mnt/usb1 and the SSD is mounted to /mnt/drive Method 1 – Utilize the EOS event handler to schedule log synchronization at prescribed intervals a) Create the log file on USB or SSD: switch#bash touch /mnt/<usb1 or drive>/eoslog b) Configure the event scheduler: switch(config)#schedule synclog interval <minutes>...
Continue reading →