Sflow samples can be augmented with additional Extended gateway data by getting data from BGP in addition to

Enable egress sFlow to sample traffic sent to any DANZ Monitoring Fabric (DMF) Recorder Node (RN) attached to the fabric. Examining these sampled packets on a configured sFlow collector allows the identification of post-match-rule flows recorded by the RNs without performing a query against the RNs. While not explicitly required, Arista Networks highly recommends using the DMF Analytics Node (AN) as the configured sFlow collector, as it can automatically identify packets sampled utilizing this feature.

Flow Analytics (Beta). NOTE: This is a beta feature in the 2019.1.0 and 2020.1.0 release and is not enabled by

sFlow is a sampling technique which monitors the incoming traffic on all the interfaces without affecting the network performance.

Mirror on drop is a network visibility feature which allows monitoring of MPLS or IP flow drops occurring in the ingress pipeline. When such a drop is detected, it is sent to the control plane where it is processed and then sent to configured collectors. Additionally, CLI show commands provide general and detailed statistics and status.

An interface may be a source for both a mirroring session and sFlow at the same time. For more information about mirroring and ingress and egress sFlow look in the Resources section below.

Sampled flow tracking with IPFIX export is supported on most of the Arista platforms. User configured sampling rate is used for sampling in ingress and/or egress direction on the configured interfaces. An EOS software agent on CPU processes samples received from hardware, samples are used to create flow records that are exported to IPFIX collectors. Refer to Sampled flow tracking TOI for additional details.

Network administrators require access to flow information that passes through various network elements, for the purpose of analyzing and monitoring their networks. This feature provides access to IP flow information by sampling traffic flows in ingress and/or egress directions on the interfaces on which it is configured. The samples are then used to create flow records, which are exported to the configured collectors in the IPFIX format. Egress Flow tracking is supported from EOS-4.29.0F on the DCS-7170B-64C series and supported on 7280, 7500 and 7800 series platforms from EOS-4.31.1".

Sflow samples can be augmented with additional Extended gateway data by getting data from BGP in addition to

When packets are encapsulated in tunnels via protocols such as GRE, sFlow samples with version 5 default extensions

The sFlow source IP address (also known as the agent IP address) is placed in the sFlow datagrams that the switch sends

Sflow 4.27.0F

Packets sampled for sFlow are packaged in a flow sample structure containing, amongst other things, input and output

Packets sampled for sFlow are packaged in a flow sample structure containing, amongst other things, input and output

sFlow is a technology for monitoring traffic in data networks containing switches and routers. This document details supported platforms for the sFlow Version 5 specification, as well as which platforms are supported for various flow_data and sample_data types.

The sFlow VPLS extension adds support for providing VPLS-related information to sFlow packet samples, for VPLS forwarded traffic. Specifically, for customer traffic ingressing on a CE-facing PE interface in a VPLS deployment that uses statically configured LDP pseudowires, information such as the name of the VPLS instance and the ID of the pseudowire that the packet will egress over will be included in the sFlow datagram.

The sFlow VPLS extension adds support for providing VPLS-related information to sFlow packet samples, for VPLS forwarded traffic. Specifically, for customer traffic ingressing on a CE-facing PE interface in a VPLS deployment that uses statically configured LDP pseudowires, information such as the name of the VPLS instance and the ID of the pseudowire that the packet will egress over will be included in the sFlow datagram. 

This feature adds support for configurable max sFlow datagram size. The current default max datagram size is 1400 bytes, which can cause some sFlow datagrams to be dropped when there is an MTU set. This feature enables the configuration of the max datagram payload size within the range of 200 to 1500 bytes to help avoid fragmentation. Note that this feature only configures software sFlow and is not supported on hardware-accelerated sFlow.

The feature allows egress sFlow sampling to be enabled per a subinterface. The egress sFlow sampling per a subinterface configuration will only have effect when egress sFlow sampling is disabled on the parent interface as egress sFlow sampling on the parent interface includes traffic on all subinterfaces.

sFlow is a multi-vendor sampling feature that helps to monitor application level traffic flow. For ingress sFlow, sampling can be configured on a set of interfaces and port-channels where the application data is flowing inbound.

The pre-existing "show sflow" command has a "Number of datagrams" field that indicates the total number of datagrams sent to all sFlow collectors. This feature will add finer granularity by allowing users of software sFlow to view the number of datagrams sent to each sFlow collector.

Sflow EOS 4.30.1F

The pre-existing "show sflow" command has a "Number of samples" field that indicates the total number packets sampled across all sFlow enabled interfaces. This feature will add finer granularity by allowing users of software sFlow to view the number of packets sampled at each sFlow enabled interface in the ingress and egress directions.

Sflow EOS 4.30.1F

By default, sFlow samples that are generated have a fixed size: 128 bytes. This feature adds support for a

This feature adds support for a selected set of configured interfaces to collect egress flow samples. Egress sFlow can be configured on ethernet and port-channel interfaces.

This feature allows Octa to act as a collector for IPFIX and sFlow datagrams and to aggregate and stream the collected data in response to a gNMI subscription. Octa is a process in EOS which combines OpenConfig and certain TerminAttr functionality, primarily with the intent of servicing gNMI requests for OpenConfig paths and for "EOS native" paths.