Tag :: Logging

This feature allows the logging of packets matching deny rules in ingress ACLs applied on subinterfaces. This behavior can be enabled by using the log keyword when configuring an ACL deny rule. A copy of the packet matching those ACL rules is sent to the control plane, where a syslog entry of the packet header is being generated.

This feature adds the support for a standby server to the existing syslog logging mechanism for UDP syslog servers. The user can specify a logging group and specify remote syslog servers. The first host configured will be the “active” server, which means syslogs will be forwarded to that host whenever it is reachable via ICMP. The second host will be the “standby” server, which will receive syslogs if the active server goes down. This provides more robustness for setups with multiple potential syslog servers.

This document describes how to prefix syslog messages with a custom string value. Previously, syslog messages were constrained to being prefixed with either the device’s hostname, IPv4 address or fully qualified domain name. This can be controlled with the command “logging format hostname ( fqdn | ipv4 )”. Support has now been added for prefixing the syslog messages with a custom comment. This provides users with greater freedom when deciding the format of their syslog messages including those which are sent to syslog servers.

This feature allows generating the syslog message for the packets matching rules in egress ACLs. This can be enabled using the log keyword when configuring an ACL rule. A copy of the packet matching such an ACL rule is sent to the control plane, where a syslog entry for the packet header is generated.

The EOS Event Manager feature, introduced in 4.17.0F,  provides the ability to specify a condition and an action

This feature allows the logging of the packets matching rules in ingress ACLs. This behavior can be enabled by using the log keyword when configuring an ACL rule. A copy of the packet matching those ACL rules is sent to the control plane, where a syslog entry of the packet header is being generated.

A fundamental business requirement for any network operator is to reduce costs where possible. For network operators, deploying devices to many locations can be a high cost, as sending trained specialists to each site for installations is both time-consuming and expensive. Arista devices support Zero Touch Provisioning (ZTP), a bootstrapping strategy that enables devices to obtain configuration data with no installer action beyond physical placement and connecting network and power cables. Secure Zero Touch Provisioning (SZTP) builds on ZTP and securely supports provisioning as defined in RFC 8572.

This feature adds the support for tracking the number of syslog messages sent to the server and the number of syslog messages received on the server, along with other log forwarding action statistics, continuously within the existing syslog logging mechanism.

This feature adds TLS support to the existing syslog logging mechanism. With the new added CLI commands, the user can