Network

This chapter describes the dashboards on the Network tab to transmit the data onthe DANZ Monitoring Fabric Controller. It includes the following sections.

Rates

The Network → Rates dashboard summarizes information aboutthe analysis of the rates, congestion, and packets in Wireshark and provides the following panels:

  • Flow Rate: Calculates and displays the flow rate in Mbps over a selected time range by summing the upsampledByteCount field and applying a mathematical transformation to derive the bit rate per second.
  • Count of Flows with Congestion TCP Flags: Displays the count of flows with congestion TCP flags over a selected time range, grouping and stacking the results based on the top flow identifiers.
Figure 1. Network > Rates Dashboard

Tunnel

The Network → Tunnel dashboard summarizes information about flows and its composition for the bytes and data and provides the following panels:

  • Flows: Displays the distribution of flows based on the sum of bytes across the top flow types over a selected time range, using a treemap for easy comparison.
  • Composition: Displays the percentage composition of different Tunnel flow types based on the sum of bytes over a selected time range, using a vertically stacked bar chart for comparison.
Figure 2. Network > Tunnel Dashboard

Troubleshooting

  • Verify records are arriving for sFlow® on the home page of the Analytical Node.
  • In Kibana Discover, select data-view flow-sflow-* to determine if any records are arriving.
  • Check the agt field to see if the switch sends sFlow, and the AN parses and shows records.
  • Verify the records contain fields proto, eType, dP, sP. These are the fields required by this feature to categorize tType to MPLS, GRE, GTP, IPinIPv4, IPinIPv6, and VXLAN.

Drop (MoD)

The Network → Drop (MoD) dashboard provides reasons by analyzing overall drops and drops by flow for dropped packets as a Mirror on Drop (MoD) Flow sFlow collector.

The dashboard displays the following panel:
  • Top Dropping Flows: Displays the top flows experiencing the highest packet drops, grouped by flow name and based on the sum of drops over a selected time range.
  • Drops by Time: Displays the trend of packet drops over a selected time range, plotting the sum of drops against time to highlight when network congestion or loss events occurred.
Figure 3. Network > Drop (MoD) Dashboard -Top
Thebottom dashboard displays the following panel:
  • Top Drop Reasons: Displays the top reasons for packet drops over a selected time range by counting the occurrences of different discard reasons.
  • Dropped Packets: Displays the detailed records of dropped packets over a selected time range, including fields like flow information, drop count, and discard reason.
Figure 4. Network > Drop (MoD) Dashboard -Bottom

Troubleshooting

  • Verify records are arriving for sFlow® on the home page of the Analytical Node.
  • In Kibana Discover, select data-view flow-sflow-* to determine if any records are arriving.
  • Check the agt field to see if the switch sends sFlow, and the AN parses and shows records.
  • Verify the records contain field drops & discard_reason.

Hop-by-Hop

The Network → Hop-by-Hop dashboard provides information about multihop bytes and data.

The dashboard displays the following panel:
  • MultiHop Bytes & Latency: Displays the distribution of flows based on the multiple hopping of the bytes across the top flow types.
Figure 5. Network > Hop-by_Hop Dashboard

TCP Analysis

The TCP Analysis dashboard provides information about multihop bytes and data.

The dashboard displays the following panel:
  • TCP Health Flows: Displays the count of TCP health flows observed through Dapper for different flow types over a selected time range, helping monitor network performance and detect anomalies.
  • TCP Window LineChart: Displays the average TCP window size and flight size metrics over a selected time range to monitor flow control behavior and congestion trends as part of TCP Analysis (Dapper).
  • Incidence TCP Network Loss: Displays the number of TCP retransmissions over a selected time range to monitor packet loss and network reliability as part of TCP Analysis (Dapper).
The lower dashboard includes::
  • Incidence of Zero TCP Window: Displays the number of Zero TCP Window events over a selected time range to monitor periods when receivers are unable to accept more data, helping assess congestion and flow control issues as part of TCP Analysis (Dapper).
  • Timings LineChart: Plots the average Round-Trip Time (RTT) and Sender Reaction Time across a selected time range to help monitor network latency and transmission responsiveness as part of TCP Analysis (Dapper).

DMF Recorder Node

This section describes Arista Analytics to use with the DANZ Monitoring Fabric Recorder Node. It includes the following sub-sections.

Overview

The DMF Recorder Node captures network packets to disk, enabling rapid and efficient retrieval of specific packets. A single DANZ Monitoring Fabric Controller manages multiple DMF Recorder Nodes. The Controller uses DANZ Monitoring Fabric policies to direct packets to the recorders. The Controller provides APIs for:
  • Querying packets across multiple recorders.
  • Viewing recorder status, statistics, errors, and warnings.

DANZ Monitoring Fabric Policy determines matching packets to one or more recorder interfaces. The DMF Recorder Node interface defines the switch and port where the recorder connects to the fabric. A DANZ Monitoring Fabric policy treats these as delivery interfaces.

The recorder node visualization is present in both NetFlow and TCPflow dashboards.

General Operation

To retrieve packets from the DMF Recorder Node for analysis using Arista Analytics, select the Controller and log in from the Recorder Node window on the NetFlow or Flows dashboard. To add a new Controller, click the small Select Controller icon and add the Controller. After logging in to the DMF Recorder Node, the system displays the following dialog:
Figure 6. DMF Recorder Node

The Recorder Node window can compose and submit a query to the DMF Recorder Node. Select any of the fields shown to create a query and click Submit. The Switch Controller link at the bottom of the dialog can log in to a different DMF Recorder Node.

Select the Recorder Summary query to determine the number of packets in the recorder database. Then, apply filters to retrieve a reasonable number of packets with the most interesting information.

You can modify the filters in the recorder query until a Size query returns the most beneficial number of packets.

Query Parameters

The following parameters are available for queries:
  • Query Type
    • Size: Retrieve a summary of the matching packets based on the contents and search criteria stored in the recorder node. Here, Size refers to the total frame size of the packet.
    • AppID: Retrieve details about the matching packets based on the contents and search query in the recorder node datastore, where the packets are stored. Use this query to see what applications are in encrypted packets.
    • Packet Data: Retrieve the raw packets that match the query. At the end of a search query, it generates a URL pointing to the location of the pcap if the search query is successful.
    • Packet Objects: Retrieve the packet objects that match the query. At the end of a search query, it generates a URL pointing to the location of the objects (images) if the search query is successful.
    • Replay: Identify the Delivery interface in the field that appears, where the replayed packets are forwarded.
    • FlowAnalysis: Select the flow analysis type (HTTP, HTTP Request, DNS, Hosts, IPv4, IPv6, TCP, TCP Flow Health, UDP, RTP Streams, SIP Correlate, SIP Health).
  • Time/Date Format: Identify the matching packets' time range as an absolute value or relative to a specific time, including the present.
  • Source Info: Match a specific source IP address/MAC Address/CIDR address.
  • Bi-directional: Enabling this will query bi-directional traffic.
  • Destination Info: Match a specific destination IP address/MAC Address/CIDR address.
  • IP Protocol: Match the selected IP protocol.
  • Community ID: Flow hashing.
Additional Parameters
  • VLAN: Match the VLAN ID.
  • Outer VLAN: Match the outer VLAN ID when multiple VLAN IDs exist.
  • Inner/Middle VLAN: Match the inner VLAN ID of two VLAN IDs or the middle VLAN ID of three VLAN IDs.
  • Innermost VLAN: Match innermost VLAN ID of three VLAN IDs.
  • Filter Interfaces: Match packets received at the specified DANZ Monitoring Fabric filter interfaces.
  • Policy Names: Match packets selected by the specified DANZ Monitoring Fabric policies.
  • Max Size: Set the maximum size of the query results in bytes.
  • Max Packets: Limits the number of packets the query returns to this set value.
  • MetaWatch Device ID: Matches on device ID/serial number found in the trailer of the packet stamped by the MetaWatch Switch.
  • MetaWatch Port ID: Matches on application port ID found in the trailer of the packet stamped by the MetaWatch Switch.
  • Packet Recorders: Query a particular DMF Recorder Node. Default is none or not selected; all packet recorders configured on the DANZ Monitoring Fabric receive the query.
  • Dedup: Enable/Disable Dedup.
  • Query Preview: After expanding, this section provides the Stenographer syntax used in the selected query. You can cut and paste the Stenographer query and include it in a REST API request to the DMF Recorder Node.

Using Recorder Node with Analytics

For interactive analysis, any set of packets exceeding 1 GB becomes unwieldy. To reduce the number of packets to a manageable size, complete the following steps:

  1. Select the Summary query to determine the number of packets captured by the Recorder. Apply filters until the packet set is manageable (less than 1 GB).
  2. Search over the metadata from all sources and analyze it to retrieve a limited and useful set of packets based on source address, destination address, timeframe, and other filtering attributes.
  3. Submit the Stenographer query, which is used by the DMF Recorder Node and automatically composed by Arista Analytics.

    You can perform flow analysis without downloading the packets from Recorder. Select specific rows to show Throughput, RTT, Out of order, and Re-transmissions. Packet varieties like HTTP, HTTP request, DNS, Hosts, IPv4, IPv6, TCP, TCPFlow Health, UDP, RTP Streams, SIP Correlate, and SIP Streams analyze the flows. Then, sort and search as required and save to CSV for later analysis. You can search over a given duration of time for the IP address by exact match or prefix match.

    The Replay set directs large packets to an archive for later analysis; this frees up the Recorder to capture a new packet set.

    Use DMF Recorder Node to identify the applications on your network that are encrypting packets. Select a Recorder Detail query to see the applications with encrypted packets.

    Refer to the DANZ Monitoring Fabric Deployment Guide for information about installing and setting up the DMF Recorder Node. For details about using the Recorder from the DANZ Monitoring Fabric Controller GUI or CLI, refer to the DANZ Monitoring Fabric User Guide.

System

This chapter describes the dashboards on the System tab to configure the DANZ Monitoring Fabric Controller and alerts. It includes the following sections.

Configuration

This dashboards on the Configuration tab configures the alerts and analytics for the DANZ Monitoring Fabric Controller for different settings and configurations. It has the following sections:
  • Configure Alerts
  • Analytics Configuration

Configure Alerts

This dashboards on the Configuration tab configures the alerts for the DANZ Monitoring Fabric Controller for different settings. It has the following settings:
  • SMTP Settings
  • Syslog Alert Settings
The Configure Alert tab has following options:
  • Production Traffic Mix Alert (sFlow)
  • Monitoring Port Utilization Alert
  • New Host Report
Figure 1. System > Configure Alerts

Analytics Configuration

This tab describes the configurations of Arista Analytics. It includes the following sections:
Figure 2. System > Analytic Configuration

DHCP to OS

DHCP signatures can map to known operating systems. These unique signatures are from https://www.fingerbank.org/. As shown in the following image, several two-digit numbers are assumed signatures of each OS (derived from fngerbank.org).
Figure 3. Unique OS Signatures from fingerbank.org
Figure 4. OS Information Received through DHCP Signatures

IP Address Blocks

Map an IP address or a range of addresses to a description, which searches for description text instead of the IP address. This feature identifies a specific group or organization sending or receiving traffic.

Complete the following steps to assign a single IP address or a block of IP addresses to a tool, group, or organization.

  1. Select System > Configuration and click the Edit control to the left of the IP Block section.
    Figure 5. Edit IP Blocks
  2. Copy an existing block by clicking on any square box along the left and select Duplicate from the pop-up menu.

    The duplicated block will be appended to the existing block list and assigned the next numerical sequence identifier.

  3. Scroll down to the end of the tags section to the numerical identifier assigned to the new block.
    Figure 6. Key Value Pairs
    It automatically copies the first four keys. The purpose of each of these default keys is as follows.
    • Desc: A short descriptive text entry.
    • ASNum: Automatically populated with the BGP Autonomous Systems (AS) numbers for well-known networks.
    • VPC: Virtual Private Cloud (tenant), automatically populated with the VPCs used in an integrated Converged Cloud Fabric network.
    • Segment: Network segment within a Converged Cloud Fabric VPC.

    To identify a user, application, tool, group, or organization, use the Desc key. You can leave the other fields blank.

  4. Type a value for the Desc key in double quotation marks (“).
  5. (Optional) To define an additional key, select any key and choose Duplicate from the pop-up menu. Then, type over the existing value with the correct value for the new key.

    Existing dashboards use the default keys. The customized dashboards can use added key pairs. The fifth and sixth keys can be custom.

    The source and destination IPv4 address have these keys for the flow. For example, the source description would be sDesc, and the destination description would be dDesc.
    Note: Remember to match values in the same order as the corresponding key positions.

NetFlow Stream

Arista Analytics may consolidate NetFlow records to improve performance.

The Analytics server/cluster consolidates flows received within two seconds into a single flow when the source and destination IP addresses are the same, or the source or destination L4 protocol port is the same.

For example, ten flows received by the Analytics server within 30 seconds are consolidated into a single flow if the source and destination IP addresses and destination port are the same for all the flows and only the source ports are different or if the source and destination IP addresses and source port are the same for all the flows and only the destination ports are different. This consolidated flow displays as a single row.

By default, the NetFlow Optimization is enabled for Netflow v5 and disabled for Netflow v9 and IPFIX. To allow the Netflow Optimization for Netflow v9 and IPFIX, refer to the Netflow v9/IPFIX Records section.

This consolidation improves Analytics NetFlow performance, allowing more efficient indexing and searching of NetFlow information.

The following figure shows the NF Detail window on the NetFlow dashboard, which provides an example of NetFlow information with optimization.
Figure 7. Analytics NetFlow Optimization
NetFlow Traffic from Third-party Devices
This section displays third-party device and interface names. It shows hop-by-hop forwarding of flows when NetFlow traffic comes from a third-party device. For a query for a specific flow, Arista Analytics shows the device and interface names associated with that flow. If the flows go through two hops, it displays the device and interface names associated with flows.

Arista Analytics can act as a NetFlow collector for third-party devices. In this case, Arista Analytics displays third-party device management IP addresses and the interface index (iFindex) of the interface for each NetFlow-enabled third-party device.

For example, the nFlow by Production Device & IF window shows that 10.8.39.198 is the third-party device that forwards NetFlow traffic. The iFindex of the interface on that device where NetFlow is enabled is 0, 2, 3, 4.

To discover the device name and the actual interface name rather than the iFindex, Arista Analytics automatically does an SNMP walk by getting the third-party device management IP from flow information. By default, Analytics uses the SNMP community name public to get the device name and interface name. If the SNMP community name of the third-party device is not public, change it in the Arista Analytics SNMP collector configuration.
Note: Analytic Node DMF 8.3.0 release supports both SNMPv2 and SNMPv3.
Note: For IPFIX and nFlow v9, configure the third-party device to send the iFindex. The Analytics node will do an SNMP walk to get the interface names associated with that iFindex. By default, it does not send the iFindex with IPFIX or nFlow v9. For example, to send the iFindex for IPFIX and nFlow v9, enable match interface input snmp and match interface output snmp under flow record configuration on the third-party device.

DMF Analytic > System > Configuration > Analytic Configuration > snmp_collector

Arista Analytics then performs SNMP polling and displays the third-party device name and the actual interface name in the nFlow by Production Device & IF window.

To perform the SNMP configuration, complete the following steps:

  1. On the screen shown later, click DMF Analytic > System > Configuration > Analytic Configuration > snmp_collector > Edit .
    Figure 8. Analytic snmp_collector config
    The system displays the following edit dialog.
    Figure 9. Analytic Configuration > snmp_collector > Edit Dialog (SNMPv2 Configuration)
    Figure 10. Analytic Configuration > snmp_collector > Edit Dialog (SNMPv3 Configuration)
  2. Click the community string public to change it to a different value, as shown in the following dialog.

    By default, the SNMP collector polls devices every 60 seconds.

  3. To change the SNMP poll interval, click the value 60, change it to the preferred value, and click Save.
After completing this configuration, the third-party device is polled for the device name and interface name, nFlow by Production Device & IF window displays it.
Figure 11. Analytic Configuration > snmp_collector > Edit Dialog

OUI

Map ARP Organizational Unique Identifiers (OUIs) for various hardware vendors.
Figure 12. OUIs of Various Hardware Vendors

Ports

The Analytics Node maps typically used ports for their L4 applications.
Figure 13. Edit Ports

Protocols

The Analytics Node maps protocols as following. These protocols can also be user defined for custom application custom protocols.
Figure 14. Edit Protocols

SNMP Collector

SNMP collectors facilitate third-party NetFlow or IPFIX sources. The Analytics Node supports both SNMPv2 and SNMPv3.
Figure 15. SNMP Collector

Topic Indexer

Description

The Analytics Node (AN) incorporates a feature known as topic_indexer, designed to facilitate data ingestion from customer Kafka topics and its subsequent storage into Elasticsearch indices.

This process involves modifying field names and specifying the supported timestamp field during the ingestion phase. The renaming of field names enables the creation of dashboards used to visualize data across multiple streams, including DNS and Netflow.

The resulting indices can then be leveraged as searchable indices within the Kibana user interface, providing customers with enhanced search capabilities.

Implementation Details
  • Configure a stream job using topic_indexer. Access the setting via the Kibana dashboard in the analytics node.
  • Locate the topic_indexer configuration on the Fabric Dashboard: Analytics > Fabric > System > Analytics Configuration , as shown in the following screenshots.
  • Figure 16. Analytics > Fabric
  • Another view:
    Figure 17. System > Analytics Configuration
  • The design section shows the configuration for a topic.
  • Figure 18. Node selection
Configuration
Kibana Configuration
  • To perform the topic_indexer configuration, select the System > Configuration > Fabric page and open the Analytics Configuration panel:
    Figure 19. System > Configuration
  • Figure 20. Topic_indexer configuration
Field Details
Each topic maps in JSON with the following fields:
  • topic: Kafka topic name; type string and is a mandatory field.
  • broker_address: Broker address(es), this is of type array; this will be of format [IPv4|hostname:Port number] and is a mandatory field.
  • consumer_group: This is an optional field; however, there is always a consumer group if not specified explicitly in the configuration. It is topic_name + index_name. Setting this field is particularly useful when ingesting multi-partitioned topics from the client's end.
  • index: A dedicated index name for the topic; type string. In Elastic Search (ES), it is created as topic_indexer_<index_name> and is a mandatory field.
  • field_group: An optional JSON field mapping to specify any column rename/format transformations. It specifies the format for modifications to incoming data.
  • type: To set the timestamp field as the type.
  • source_key: The source field name in the incoming data.
  • indexed_key: The destination field name inserted in the outgoing ES index.

    The indexed_key may be a @timestamp field of an ES index. If you do not specify a @timestamp field, topic_indexer automatically picks the received time of the message as the @timestamp of that message.

  • format: Data format for the field (ISO8601).
Standards and Requirements

Input fields naming convention:

  • Kafka allows all ASCII Alphanumeric characters, periods, underscores, and hyphens to name the topic. Intopic_indexer, legal characters include: a-z0-9\\._\\-
  • Note that the only restriction topic_indexer has is on capitalizing topic names. topic_indexer does not support case-sensitive names. By default, topic_indexer treats the name as a lowercase topic. Hence, topic names should be lowercase only.
  • All numeric names are also invalid field text.
Note: These conventions are valid for all other input types as well.

Examples of names:

Valid text:
  • my-topic-name
  • my_topic_name
  • itlabs.mytopic.name
  • topic123
  • 123topic
  • my-index-name
Invalid text:
  • myTopicName
  • ITLabs-Website-Tracker
  • 12435
  • MY-Index-name
Broker Address Format:
  • A broker address in Kafka comprises two values: IPv4 address and Port Number.
  • When entering the broker address, select the format IPv4:PORT.
Application Scenario

Querying Across DataStream using runtime-fields

Use runtime fields when making complex changes beyond simply renaming a field, such as converting it from a string type to an IP address. After every change to a runtime field, issue a
POST <stream-name>/_rollover 
Note: These changes are not persistent. Reapply is a must after any restart of AN.
Use Case:
  • Cross-index visualization - two data streams that need cross-querying:
  • Figure 21. Cross index visualization
  • Step 1. To view the documents in these indexes, create an index pattern (e.g., topic*spend) in Kibana.
  • Step 2. View the data in the Discover dashboard.
    Figure 22. Discover dashboard
  • Step 3. Create a common field (runtime field) between the two data streams by applying an API in Dev Tools.
    Figure 23. Dev Tools
    Note: Setting rollover policy on runtime fields can also be done in Dev Tools, as shown in the following examples:
    POST /topic-indexer-service-spend/_rollover
    POST /topic-indexer-product-spend/_rollover
    Note: These changes are not persistent. Reapply is a must after any restart of AN.
  • Step 4. Finally, create a visualization using this common field, for example, Customer. The following illustration shows the Top 5 customers with the highest spending across products and services.
    Figure 24. Visualization
Syslog Messages
The topic_indexer logs are stored in /var/log/analytics/ folder and are accessed using the following commands.
an> debug bash
admin@an$ cd /var/log/analytics/
admin@an:/var/log/analytics$
admin@an:/var/log/analytics$ ls -ls topic_indexer.log
67832 -rw-rwxr-- 1 remoteuser root 69453632 Apr 27 11:05 topic_indexer.log
Troubleshooting
Following are some of the commonly known issues and their troubleshooting scenarios:
  1. The Save button in the topic_indexer config is disabled.
    When editing the configurations of topic_indexer in the Kibana User interface, default validations appear to ensure the correctness of the values entered in the fields. Specific standards and requirements are associated with filling in the configuration for topic_indexer, as stated in the earlier section. It may encounter validation errors when entering an invalid value in the configuration field as follows.
    Figure 25. Validation errors

    In such an event, the edited configuration will not save. Therefore, before saving the configuration, validate the fields and ensure there is no visible validation error in the topic_indexer configuration editor.

  2. The index for the topic_indexer has not been created.

    After entering the correct fields in the topic_indexer configuration, the topic_indexer service will start to read the Kafka topic as documented in the configuration and load its data into the ElasticSearch index entered by the index field. The topic_indexer_ prefixes the name of the index.

    There is a wait time of several minutes before the index is created and loaded with the data from the Kafka topic. In the event the index is not created, or there is no index shown with the name topic_indexer_<index_name> value, Arista Networks recommends using the following troubleshooting steps:
    1. Check the configurations entered in the topic_indexer editor again to see whether the spellings of the topic name, broker address configuration, and index name are correct.
    2. Verify the broker address and the port for the Kafka topic are open on the firewall. Kafka has a concept of listeners and advertised.listeners . Validate if the advertised.listeners are entered correctly into the configuration. Review the following links for more details:
      1. Kafka 3.5 Documentation
      2. Kafka Listeners – Explained | Confluent
    3. If all the earlier steps are correct, check now for the logs in the Analytics Node for the topic_indexer.
      Steps to reach the topic_indexer.log file in the AN node:
      1. Secure remote access into the AN using the command line: ssh <user>@<an-ip>
      2. Enter the password for the designated user.
      3. Enter the command debug bash to enter into debug mode.
      4. Use the sudo user role when entering the AN node, hence the sudo su command.
      5. topic_indexer logs reside in the following path: /var/log/analytics/topic_indexer.log
      6. Since this log file can be more extensive, you should use the tail command.
      7. Validate if the log file shows any visible errors related to the index not being created.
      8. Report any unknown issues.
  3. Data is not indexed as per the configuration.
  4. Data ingestion is paused.

    When experiencing issues 3 or 4 (described earlier), use the topic_indexer log file to validate the problem.

  5. The index pattern for the topic_indexer is missing.

    In the Kibana UI, it creates a default topic_indexer_* index pattern. If this pattern or a pattern to fetch the dedicated index for a topic is missing, create it using the Kibana UI as described in the following link:

    https://www.elastic.co/guide/en/kibana/8.15/data-views.html

Integration

This section identifies specific applications or operating systems running on network hosts.

Integrating Analytics with Infoblox

Infoblox provides DNS and IPAM services that integrate with Arista Analytics. To use, associate a range of IP addresses in Infoblox with extensible attributes, then configure Analytics to map these attributes for the associated IP addresses. The attributes assigned in Infoblox appear in place of the IP addresses in Analytics visualizations.

Configuring Infoblox for Integration
Complete the following steps to configure Infoblox for integration with Arista Analytics to recognize the IP address ranges assigned in Infoblox.
  1. Log in to Infoblox System Manager.
  2. Use the Edit icon to Add, Modify, or Delete the Integration configuration.
    Figure 26. Integration Configuration
    Enter the required information in the Integration input fields:
    • Host: Must be a DNS-resolvable hostname or IPv4 address.
    • Username: Enter the username of the Infoblox integration.
    • Password: Enter the password of the Infoblox integration. When entering the password, it masks the password.
    • Keys Fetched: Accepts a list of field names and field values:
      • Field name
      • Field value
    Note: The configuration has data as a JSON object in earlier releases.
    Figure 27. Integration
  3. Select +Add Field to add fields for Keys Fetched input or use to remove the corresponding field. Hovering over displays the requirements for the input field.
    Figure 28. Add Field Requirement
    There are also validation checks when entering configuration values.
    Figure 29. Validation Checks
  4. Select Submit to save the configuration after entering all the required fields; the page will refresh.
  5. Select Delete to delete the integration configuration; the page will refresh.
    Figure 30. Delete Integration
  6. To set the extensible attributes in Infoblox, click the Administration Extensible Attributes tab.
    Figure 31. Extensible Attributes Tab
    This tab defines the attributes applied to a block of IP addresses. The extensible attributes you define for integrating Infoblox with Arista Analytics are as follows:
    • EVPC: Identifies the Enterprise Virtual Private Cloud (EVPC) assigned to a block of IP addresses in Infoblox.
    • Segment: Identifies the specific subnet interface for an assigned IP address.
  7. To assign an IP address range to the VPC extensible attribute, click Data Management IPAM.
  8. Save the configuration.

    As a result of these configuration changes, view the following enhancements to the flow records in the Production Network > sFlow tab and move to the Flows by Time chart.

    Figure 32. Dashboard - sFlow

    Suppose the sFlow packet source and/or destination IP addresses fall within the IP subnets in the Infoblox IPAM dashboard. In that case, their flow records will be augmented with the extensible attributes from Infoblox as specified in the integration configuration.

    For example, the source and destination IP addresses of the 10.240.155.0/HQ:54149 > 10.240.155.10/HQ/HTTPS flow fall within the 10.240.155.0/24 subnet in the Infoblox IPAM dashboard.

    When expanding this flow in the Flows by Time chart, since VPC is in the integration keys_fetched, the sVPC value is VPC155.

    Site is in the integration keys_aliased values, and a sSite value of HQ appears. Since Desc is aliased to Site (an extensible attribute), sDesc takes on the Site's value. Segment is in the keys_aliased values; hence, sSegment with S155 appears.

    Observe similar attributes for the destination IP address in the flow record. All these values come from the Infoblox IPAM dashboard shown earlier. ASNUM does not appear as a field in the flow record despite being in the integration keys_aliased values because it is not configured or associated as an extensible attribute to the subnets in the Infoblox IPAM dashboard.

    Figure 33. Flow by Time
    Known Issue:
    • When removing a tag in the middle of the ip_block tags list and saving the configuration, the relevant flow records may have incorrect values in their attributes during the minute following this change. After this brief period, the flow records will have the correct attributes and corresponding values.
Troubleshooting

When the flow records augmented with Infoblox extensible attributes are missing these attributes, verify that the Infoblox credentials you provided in the integration configuration are correct. After confirming the credentials and the relevant flow records are still missing the Infoblox extensible attributes, generate a support bundle and contact Arista Networks TAC.

Status

Selecting System → Status displays the status of the data transmitted on the Analytic Node.

The dashboard displays:
  • Recent 15m Event Load %: Displays the analytics node's recent event processing load percentage over a selected time range, helping monitor system performance.
  • Recent 15m Query Load%: Displays the analytics node's recent query processing load percentage over a selected time range, helping monitor system performance
  • Event Load: Displays the event processing load across analytics nodes over a selected time range, helping monitor node performance and traffic handling capacity.
  • Query Load: Displays the query processing load across analytics nodes over a selected time range, helping monitor query activity and node utilization.
Figure 34. System > Status Dashboard - Top
The bottom dashboard includes:
  • Logstash Event Throughput: Displays the volume of events processed by Logstash nodes over a selected time range, helping monitor analytics node ingestion performance.
  • Query Latency: Displays the average query response time across analytics nodes over a selected time range, helping monitor query performance and system responsiveness.
  • Estimated Retention: Displays the estimated retention capacity of the analytics nodes over a selected time range, helping monitor storage trends and plan for data management.
Figure 35. System > Status Dashboard - Bottom

About

Selecting System → About displays the information about the Analytic Node.

Figure 36. System-About

DMF

This chapter describes uses the dashboards on the DMF tab to monitor activity on the DANZ Monitoring Fabric Controller. It includes the following sections.
Note: Information displayed on these dashboards requires configuring an ACL for Redis and replicated Redis using the Analytics CLI after first boot configuration.

Policy

The DMF → Policy dashboard summarizes information about DANZ Monitoring Fabric policy activity and provides the following panels:

  • Top Active Policies: Displays the top active policies based on the sum of bit rates over a selected time range, helping identify which policies contribute the most to traffic.
  • Top Filter Interfaces: Displays the top filter interfaces based on the sum of bit rates over a selected time range, allowing identification of interfaces handling the most traffic.
  • Top Service Interfaces: Displays the top service interfaces based on the sum of bit rates over a selected time range, highlighting which service interfaces handle the most traffic.
  • Top Delivery Interfaces: Displays the top delivery interfaces based on the sum of bit rates over a selected time range, helping to identify which interfaces are handling the most traffic for policy delivery.
  • Mean Bit Rate: Shows the mean bit rate over a selected time range by summing bit rates across different policy types (filter, delivery, and service) and plotting the values against time.
Figure 1. DMF > Policy Dashboard - Top
The middle dashboard includes:
  • Mean Packet Rate: Shows the mean packet rate over a selected time range by summing packet rates across different policy types (filter, delivery, and service) and plotting the values against time.
  • Core Device: Shows the distribution of bit rate across core devices over a selected time range, with data aggregated by device alias names and ordered by the total sum of bit rate.
  • Policy Core Interface Bit Rate: Shows the sum of bit rates over time for core interfaces related to policy traffic, aggregated by timestamp over a selected time range.
  • Core Interface: Shows the distribution of bit rate across core interfaces over a selected time range, with data aggregated by interface names and ordered by the total sum of bit rate.
  • Policy Core Interface Packet Rate: Shows the sum of packet rates over time for core interfaces associated with policy traffic, aggregated by timestamp over a selected time range.
Figure 2. DMF > Policy Dashboard - Middle
The lower dashboard includes:
  • Records: Displays detailed raw records of policy-related statistics across various types over a selected time range, including metadata fields such as timestamps, types, bit rates, and packet counts.
  • Policies with no traffic: Lists policies with zero traffic by counting occurrences of policy names where the bit rate is zero, aggregated over a selected time range.
Figure 3. DMF > Policy Dashboard - Bottom

Use the Top Active Policies visualization to verify that your DANZ Monitoring Fabric policies are active and behaving as expected.

Use the Filter Interfaces visualization to balance the utilization of your filter interfaces and ensure that it doesn't drop any packets to analyze.

Interface

Click the DMF → Interface tab to display the following dashboard.

  • Interface Type: Displays the distribution of interface types by summing the bit rate for each type over a selected time range.
  • SVC-Del-Filter IF: Displays the distribution of traffic across different service, delivery, and filter interfaces by summing the bit rate for each interface over a selected time range.
  • Core Service (IF): Displays the sum of transmitted bit rates (txBitRate) for different core device interfaces over a selected time range.
  • Core IF: Displays the sum of transmitted bit rates (txBitRate) across core interfaces, grouped by interface name, over a selected time range.
Figure 4. DMF > Interface Dashboard - Top
The lower dashboard includes:
  • Bit Rate: Displays the average bit rates for filter, delivery, core transmit (TX), core receive (RX), service transmit (TX), and service receive (RX) interfaces over a selected time range.
  • Interface Detail: Displays detailed interface metrics, including bit rate, packet count, error rates, and other network statistics over a selected time range.
Figure 5. DMF > Interface Dashboard - Bottom

SN (Service Node)

Click the DMF → SN tab to display the following panels:

  • Service Name: Displays the count of records grouped by service name over a selected time range.
  • Service Node Transmitted Bit Rate: Displays service nodes' average transmitted bit rate per second over a selected time range.
  • Service Node Received Bit Rate: Displays the average received and applied bit rates per second for service nodes over a selected time range.
Figure 6. DMF > SN Dashboard

Select a service from the pie chart to see the statistics for a specific managed service. It will display statistics for the selected service.

Events

The DMF → Events dashboard summarizes information about DANZ Monitoring Fabric management network events and provides the following panels:

  • Events Over Time: Displays the count of different event types over a selected time range using a date histogram on the timestamp field.
  • Events: Displays the count of different event types over a selected time range, based on the eventtype.keyword field.
  • Events: Displays a timeline of bigTapevent records, showing the distribution of different event types and their details over a selected time range.
Figure 7. DMF > Events Dashboard

Production

This chapter describes the dashboards provided on the Production Network tab, which shows traffic and events on the production network interfaces connected to the DANZ Monitoring Fabric. This section includes the following sections:

sFlow®

Select the sFlow* from the left-hsnd navigation bar in Production tab, and It summarizes information from the sFlow messages sent to the Arista Analytics server from the DANZ Monitoring Fabric Controller or other sFlow agents. This dashboard provides the following panels:
  • Top Sources Dest: Configures a real-time network traffic monitoring dashboard using sFlow data, displaying flows over a selected time range grouped by source (sHost.keyword) and destination (dHost.keyword) IPs/hosts, sorted descendingly to highlight top talkers and recipients for rapid traffic pattern analysis.
  • App L4 Port: Configures a real-time sFlow traffic dashboard displaying flows over a selected time range grouped by L4 application protocols (l4App.keyword) and sorted descendingly to highlight the most active applications for quick protocol-level traffic analysis.
  • Source AS: Displays a real-time tabular view of sFlow traffic data, showing the top source descriptions (sDesc) by flow count in descending order to highlight the most active network entities over a selected time range.
  • Dest AS: Displays a real-time tabular view of sFlow traffic data, showing the top source descriptions (dDesc) by flow count in descending order to highlight the most active network entities over a selected time range.
  • Traffic over Time: Configures a time-based stacked bar chart using sFlow data, showing the sum of upsampled byte counts over a selected time range, categorized by traffic type filters to analyze traffic distribution across private, public, and link-local networks.
  • Flow by Filter Interface: Displays a donut chart using sFlow data to show the count of flow records over a selected time range, grouped by BT interface name (BTifName) in descending order to highlight the most active interfaces.
  • Flow by Production Device & IF: Displays a nested donut chart using sFlow data over a selected time range, grouping flow record counts by device and device port in descending order to identify the most active devices and their respective ports in the network.
Selecting Dashboards → sFlow displays network traffic on the Analytic Node.
Figure 1. Production > sFlow Dashboard- Top
The middle dashboardinclude:
  • Count sFlow vs. Last Wk: Tracks the rate of unique network flows per second using sFlow data over a selected time range. It compares it with the same metric from the previous week for anomaly detection and traffic trend analysis.
  • Flow QoS PHB: Configures a real-time traffic classification dashboard using sFlow data, displaying the count of flows over a selected time range grouped by Differentiated Services Code Point (DSCP) values (phb.keyword), helping identify traffic prioritization and QoS usage patterns.
  • Flow Source: Displays global network traffic sources using sFlow data over a selected time range, mapped geographically to highlight the density and distribution of flow sources across regions.
  • Flow Destination: Displays global network traffic destinations using sFlow data over a selected time range, mapped geographically to highlight the density and distribution of flow destinations across regions.
Figure 2. Production > sFlow Dashboard- Middle
The lower dashboard includes:
  • Flows by Time: Displays detailed raw sFlow traffic records over a selected time range, showing individual flow entries along with associated metadata such as source/destination vendors, byte counts, interface names, and PHB values for in-depth traffic inspection.
Figure 3. Production > sFlow Dashboard- Bottom

sFlow® Monitoring of MPLS and GRE Tunnels

Arista Analytics can process sFlow® records containing IP packets encapsulated in additional protocol headers:
  1. IPv4 and IPv6 packets encapsulated in one or more MPLS headers.
  2. IPv4 and IPv6 packets encapsulated in one or more GRE headers.
  3. Combination of (1) and (2).
  4. VXLAN encapsulated in one or more GRE headers

The following table shows the supported combinations of headers.

Table 1. Ethernet Support
1 2 3 4
Ethernet Ethernet Ethernet Ethernet
MPLS(one or more) IPv4/IPv6 MPLS(one or more) IPv4/IPv6
IPv4/IPv6 GRE + IPv4/IPv6(one or more) IPv4/IPv6

GRE + IPv4/IPv6(one or more)

TCP/UDP TCP/UDP GRE + IPv4/IPv6(one or more) UDP
    TCP/UDP VXLAN
      Ethernet
      VLAN(optional)
      IPv4/IPv6
      TCP/UDP

This feature enhances the visibility of tunnelled traffic by documenting the content of packet headers in Analytics' Elasticsearch database. It does not affect the current formatting of Elasticsearch documents containing VXLAN headers not encapsulated by any other tunnel header.

Elasticsearch Documents

It displays each encapsulated header in a JSON object whose name has an ‘e’ prefix followed by an integer corresponding to the position of the header in the packet, 1 being the outermost tunnel header. It displays the innermost header in a JSON object named innerPkt. The following is an example of such a JSON object:

"e1": {
		"encapType": "MPLS",
		"label": 90,
		"ttl": 10
	},
	"e2": {
		"encapType": "MPLS",
		"label": 91,
		"ttl": 9
	},
	"e3": {
		"encapType": "IPv4",
		"sIp": "10.99.230.30",
		"dIp": "10.51.49.227",
		"proto": 47
	},
	"e4": {
		"encapType": "GRE",
		"proto": 34525
	},{
	"sMac": "e2:d8:dd:e3:6a:57",
	"dMac": "84:3d:9c:be:a7:1a",
	
	"e5": {
		"encapType": "IPv6",
		"sIp": "4cdd:2cde:2ead:248e:1e9b:c3dc:9e3f:3d2b",
		"dIp": "9f0a:a91a:7e79:31e:78c8:e47b:1cd2:e783",
		"proto": 47
	}.
	"e6": {
		"encapType": "GRE",
		"proto": 2048
	},
	"e7": {
		"encapType": "IPv4",
		"sIp": "10.218.163.106",
		"dIp": "10.79.78.163",
		"proto": 17
	},
	"e8" {
		"encapType": "UDP",
		"sP": 9999,
		"dP": 4739
	},
	"e9": {
		"encapType": "VXLAN",
		"vni": 8888
	},
	"innerPkt": {
		"sMac": "16:af:16:2e:83:0c",
		"dMac": "e6:32:ff:5e:50:3f",
		"sIp": "10.44.66.146",
		"dIp": "10.218.200.227",
		"proto": 6,
		"sP": 7777,
		"dP": 443
	}
}	

Each header displays a different set of information.

For MPLS:
  • encapType: Always set to MPLS
  • label: MPLS label number
  • ttl: MPLS TTL
For GRE:
  • encapType: Always set to GRE
  • proto: Ethernet type
  • key: GRE key, if present
  • seqNum: GRE sequence number, if present
For VXLAN:
  • encapType: Always set to VXLAN
  • vni: VNI number
For IP headers that follow GRE headers:
  • encapType: IPv4 or IPv6
  • sIp: Source IP address
  • dIp: Destination IP address
  • proto: IP protocol number
For UDP header preceding an encapsulated VXLAN header:
  • encapType: UDP
  • sP: Source port
  • dP: Destination port

Troubleshooting

If sFlow documents do not appear in ElasticSearch, Arista Networks recommends creating a support bundle and contacting Arista TAC.

Limitations

  • Since MPLS headers do not include any information about the encapsulated packets, processing of MPLS encapsulating any header other than IPv4 or IPv6 will result in undefined behaviour.
  • It displays the IP addresses of headers that are outer-tunnelled the sFlow dashboard, but nothing beyond (e.g., UDP/TCP port number in inner headers).
  • This feature does not support the PseudoWire control word.
  • This feature supports up to 4 MPLS labels displayed on the dashboard. Packets with 5 or more MPLS labels will not appear on the dashboard, but they are present in Elasticsearch.

NetFlow

Selecting Production → NetFlow displays data transmitted on the Analytic Node.

The dashboard displays:
  • nFlows Source IP (inner) Dest IP (outer): Displays NetFlow data over a selected time range, showing the count of flows grouped by source (slp) and destination (dlp) IP addresses in descending order to identify the most active endpoints.
  • NF over Time: Displays the sum of bytes over a selected time range, with time-based aggregation on the X-axis and filtered series split by traffic direction tags (for example, internal, external, cross, self) for comparative flow analysis.
  • nFlow Live L4 Ports: Displays the count of NetFlow records over a selected time range, grouped by the l4App.keyword field using a row-based split to categorize traffic based on Layer 4 application types.
  • nFlow by Filter Interface: Displays NetFlow data as a pie chart over a selected time range, counting flow records grouped by BTifName (interface name) in descending order to highlight the top 50 interfaces by activity.
  • Recorder Node
  • nFlow by Production Device & IF: Displays NetFlow data as a nested pie chart over a selected time range, showing the count of flow records grouped first by device name and then by device port, sorted in descending order to highlight the most active sources and interfaces.
Figure 4. Production > NetFlow Dashboard - Top
The bottom dashboard includes:
  • NF Top Talkers by Flow (Table): Displays NetFlow records in a table format over a selected time range, showing flow identifiers sorted in descending order to highlight the top talkers by flows.
  • NF by DPI App Name: Displays a count of NetFlow records over a selected time range, grouped by application name (appName.keyword) to identify the most active applications in the network traffic in descending order.
  • NF Detail: Displays detailed NetFlow records over a selected time range, showing individual flow entries and associated metadata such as source/destination IPs, protocol, packet, and byte counts, enabling granular network traffic inspection.
  • NF by Qos PHB: Displays a count of NetFlow records over a selected time range, grouped by Per-Hop Behavior (phb.keyword) in descending alphabetical order to analyze differentiated services traffic classification.
Figure 5. Production > NetFlow Dashboard- Bottom

TCP Flow

Selecting Production → TCPFlow displays data transmitted on the Analytic Node.

The information on the TCP Flow dashboard depends on TCP handshake signals and deduplicates. The switch description is specified in the Description attribute of each switch, configured on the DANZ Monitoring Fabric Controller.

The dashboard displays:
  • TCP by IP Source: Displays the distribution of TCP connections over a selected time range, grouped by Source IP address (sip) and ordered by count in descending order.
  • TCP by IP Source Port: Displays the distribution of TCP connections over a selected time range, grouped by source port (sP.keyword) and sorted by connection count in descending order.
  • TCP by IP Dest: Displays the distribution of TCP connections over a selected time range, grouped by destination IP address (dlp) and ordered by count in descending order.
  • TCP by IP Dest Port: Displays the distribution of TCP connections over a selected time range, grouped by destination port (dP.keyword) and sorted by connection count in descending order.
  • TCP over Time: Displays the total bytes of TCP traffic over a selected time range, grouped by timestamp and categorized by traffic direction using tag-based filters (for example, private, public, and cross-zone flows).
  • TCP by Filter Interface: Displays the distribution of TCP connection counts over a selected time range, categorized by BT interface name using descending order of occurrence.
  • TCP By Production Device & IF: Displays the count of TCP connections over a selected time range, grouped first by device name and then by device port, using a nested pie chart.
Figure 6. Production > TCPFlow Dashboard - Top
The middle dashboard includes:
  • SYN SYNACK Connection Latency(e2e) in msec: Displays the maximum end-to-end SYN-SYNACK connection latency in milliseconds over a selected time range using a time-based line graph.
  • SYN SYNACK Connection Latency(e2e) percentiles: Displays the SYN-SYNACK end-to-end connection latency across multiple percentiles (1st, 5th, 25th, 50th, 75th, and 95th) over a selected time range using a time-series line graph.
  • TCP Top Latency Table: Displays the top TCP flows sorted by their maximum observed latency over a selected time range.
Figure 7. Production > TCPFlow Dashboard- Middle
The lower dashboard includes:
  • TCP Detail: Displays detailed TCP connection records filtered by type:tcpconnection, showing attributes such as latency, byte count, and SYN/SYNACK flags for each flow over a selected time range.
Figure 8. Production > TCPFlow Dashboard- Bottom

Flows

Selecting Production → Flows displays the network's data efficiency, high traffic monitoring and scalability on the Analytic Node.

The dashboard displays:
  • Flow Selector: Allows network traffic data to be filtered using dynamic dropdowns for Traffic Type based on tags.keyword field, enabling users to interactively refine insights over a selected time range.
  • All Flows over Time: Displays the sum of bytes for different traffic categories (for example, private, public, cross-zone, link-local, and new flows) over a selected time range, using a date histogram with 100-second intervals.
  • Live L4 Port: Displays the count of flow records grouped by L4 application port over a selected time range using the l4App.keyword field for aggregation.
  • Flows Source IP (inner) Dest IP (outer): Displays the count of flows grouped first by source IP (sip) and then by destination IP (dip) over a selected time range.
  • Recorder Node: Refer to DMF Recorder Node.
  • Flow Heatmap VPCs: Displays a heatmap of the total bytes transferred between source VPCs and destination VPCs over a selected time range.
Figure 9. Production > Flows Dashboard - Top
The lower dashboard includes:
  • All Flows Details: Displays detailed flow records filtered by flow type, including protocol, byte count, and packet count, over a selected time range.
Figure 10. Production > Flows Dashboard- Bottom

Filters & Flows

Selecting Production → Filters & Flows displays the selected MAC Address to access the Analytic Node.

The dashboard displays:
  • Top Filters: Displays the sum of bytes over time, grouped by top BTIfName values, over a selected time range.
  • Filter Top Flows: Displays the sum of bytes sent as flow traffic over time, split by BTIfName, and each segment further splits by flow1.keyword (descending)., over a selected time range.
  • Filter Bottom Flows: Displays the sum of bytes sent as flow traffic over time, split by BTIfName, and each segment further splits by flow1.keyword (ascending)., over a selected time range.
Figure 11. Production > Filters & Flows Dashboard - Top

 

Figure 12. Production > Filters & Flows Dashboard - Bottom

ARP

This data correlates with the tracked host feature on the DANZ Monitoring Fabric Controller. It shows all ARP data when you switch interface and production devices over time.

The Production → ARP displays:
  • Tracked Hosts New-Old-Inactive: Displays the count of tracked hosts categorized as newly seen, previously seen, or inactive, grouped by OUI vendor over a selected time range.
  • Tracked Hosts by Filter Interface: Displays the unique count of tracked MAC addresses grouped by filter interface over a selected time range.
  • Tracked Hosts by Production Device & IF: Displays the unique count of tracked MAC addresses grouped by production device and interface over a selected time range.
Figure 13. Production > ARP Dashboard - Top
The middle dashboard includes:
  • Tracked Hosts Over Time: Displays the unique count of MAC addresses over a selected time range using a date histogram to track the number of distinct tracked hosts seen over time.
Figure 14. Production > ARP Dashboard- Middle
The lower dashboard includes:
  • Tracked Hosts: Displays raw tracked host events over a selected time range, showing detailed logs with metadata such as timestamp, device, port, hostname, interface, and activity status.
Figure 15. Production > ARP Dashboard- Bottom

DHCP

Selecting Production → DHCP analyzes DHCP activity on the Analytic Node.

The DHCP Dashboard summarizes information from analyzing DHCP activity and provides the following panels. The dashboard displays:
  • DHCP OS Fingerprinted: Displays the distribution of fingerprinted operating systems based on the unique count of host MAC addresses over a selected time range
  • DHCP by Server & Client: Displays the top server names and associated CNAMEs based on count over a selected time range.
  • DHCP by Filter Interface: Displays the distribution of DHCP message activity by filter interface, based on count, over a selected time range.
Figure 16. Production > DHCP Dashboard - Top
The middle dashboard includes:
  • Unauthorized DHCP Server: Identifies unauthorized DHCP servers by displaying the unique number of clients they responded to with DHCP offers, excluding known valid servers, over a selected time range.
  • DHCP Server seen: Displays all DHCP servers that sent offers and the count of unique clients they responded to, excluding 0.0.0.0 addresses, over a selected time range.
  • DHCP Messages Over Time: Displays the distribution of DHCP message types (for example, discover, offer, request, ack) over a selected time range, using a date histogram split by message type.
  • DHCP Messages by Type: Displays the distribution of DHCP message types by count over a selected time range, using a pie chart segmented by the type.keyword field.
Figure 17. Production > DHCP Dashboard- Middle
The lower dashboard includes:
  • DHCP Messages: Displays a time-series histogram and detailed document table of DHCP messages filtered by type over a selected time range.
Figure 18. Production > DHCP Dashboard- Bottom

DNS

Selecting Production → DNS analyzes DNS activity on the Analytic Node.

The DNS Dashboard summarizes information from analyzing DNS activity and provides the following panels. The dashboard displays:
  • Top DNS Server: Displays the top 25 DNS servers by request count over a selected time range, using a pie chart segmented by server name.
  • Top DNS Clients: Displays the top 25 DNS clients based on query count over a selected time range, represented as pie chart segments grouped by client name.
  • DNS by Filter Interface: Displays the top 60 DNS query sources based on the BTIfName field, counted and ordered by frequency over a selected time range.
  • DNS by Production Device & IF: Displays DNS query counts grouped by production device and interface, using a nested split on device and devicePort fields over a selected time range.
Figure 19. Production > DNS Dashboard - Top
The middle dashboard includes:
  • Unauthorized DNS Server: Displays the top unauthorized DNS server, excluding a defined list of approved IP ranked by their unique client count over a selected time range.
  • DNS RTT: Displays the 95th percentile of DNS Round-Trip Time (RTT) and the query volume, aggregated over time, for all sources over a selected time range.
Figure 20. Production > DNS Dashboard- Middle
The lower dashboard includes:
  • DNS All Messages: Displays all DNS-related log messages along with key fields like client IP, server name, RTT, and query types over a selected time range.
  • DNS Rcode Distro: Shows the distribution of DNS Response Codes (RCode) based on their frequency over a selected time range.
  • DNS QType Description: Shows the distribution of DNS Query Types (QTypes) based on their frequency over a selected time range.
  • DNS Top QNames: Shows the top Queried domain Names (QNames) in DNS traffic, ranked by count over a selected time range.
Figure 21. Production > DNS Dashboard- Bottom
Note: The query and response packet timestamps compute the DNS RTT value. If a query packet does not answer by a response packet within 180 seconds, then the RTT value is set to -1.

ICMP

The ICMP Dashboard summarizes information from analyzing ICMP activity and provides the following panels.

The dashboard displays:
  • Top ICMP Message Source: Displays the top source IPs sending ICMP messages, ranked by count over a selected time range.
  • ICMP by Filter Interface: Displays the distribution of ICMP messages by filter interface (BTIName) over a selected time range.
  • Top ICM Message Dest: Displays the top destination IP addresses for ICMP messages over a selected time range.
  • ICMP by Error Description: Displays the distribution of ICMP messages categorized by error description over a selected time range.
  • ICMP by Production Device & IF: Displays ICMP message distribution grouped by production device and interface over a selected time range.
  • ICMP Top Err Dest IPs: Displays the top destination IPs associated with ICMP error messages over a selected time range.
Figure 22. Production > ICMP Dashboard - Top
The middle dashboard includes:
  • ICMP Messages Over Time: Displays the count of ICMP messages over a selected time range, broken down by traffic tags such as private, public, cross, and self, using a date histogram on the timestamp field.
  • ICMP Error Dest Port Apps: Displays the distribution of destination port applications that triggered ICMP errors over a selected time range, using a pie chart grouped by the errPortApp.keyword field and sorted by descending count.
Figure 23. Production > ICMP Dashboard - Middle
The lower dashboard includes:
  • ICMP Table: Displays a detailed table of ICMP packet metadata over a selected time range, including fields such as timestamp, source and destination IPs, device info, error descriptions, and message types for in-depth analysis.
Figure 24. Production > ICMP Dashboard- Bottom
*sFlow® is a registered trademark of the Inmon Corp.

Introduction

Arista Analytics Node provides scale-out analytics with configurable, historical time-series-based dashboards for flow visibility, health, performance, and capacity planning. It acts as a collector for NetFlow and sFlow packets to provide real-time visibility, including tunneled or encapsulated traffic, enabling the detection of security attacks like DoS/DDoS and SYN attacks. The highly intuitive and customizable GUI dashboards support a search to drill down and focus on possible issues quickly. It provides a variety of reporting and alerting functions and allows the user to easily share custom dashboard views with other team members for collaborative analysis, troubleshooting, and remediation.

It includes the following sections:

Analytics and Dashboards

Arista Analytics provides the accessibility to analyze, search, predict, and reveal patterns and relationships among data.

The following options to access Arista Analytics features:
  • Dashboard: Monitors traffic flow, network health, performance, and capacity planning. There is an option to customize dashboards.
  • Discover: Use predefined indices to filter and display specific events.
  • Machine Learning: Detect, model, and predict unusual activity or events on the network.
The Arista Analytics displays in the following tabs:
  • Production Network: This analyzes the main operational network.
  • DMF: This is for observing the dedicated monitoring network.
  • System: This configures the analytics system itself.
  • Network: This manages the analytics system.
  • VoIP: This configures the analytics system itself.
Figure 1. Production Network > Dashboard
Each tab utilizes panels that display data through:
  • Visualizations (pie charts, line graphs, etc.) based on queries.
  • An event list at the bottom shows matching events.
  • Pop-up windows for detailed information on panel mouseovers.

It provides a clear structure for monitoring and managing network performance and system settings.

The Kibana documentation documents the Analytics GUI, and most of its features and operations based on ElasticSearch are available at the following URL:

https://www.elastic.co/guide/en/kibana/8.15/index.html

Common Features and Functions

The Arista Analytics displays in the following visualizations:
  • Area: Emphasize the data between an axis and a line
  • Data Table: Displays data in rows and columns.
  • Heat map
  • Horizontal bar
  • Line
  • Metric
  • Recorder Node
  • Tag Cloud
  • Timelion
  • Vertical bar

Filtering Information on a Dashboard

The interactive filtering capabilities of the Arista Analytics dashboard:
  • Area-Based Filtering: Selecting an area on the dashboard restricts the displayed events to those similar to the selected area. It allows for context-sensitive filtering.
  • Pie Chart Slice Filtering: Clicking a slice of a pie chart filters the dashboard to show only events related to the specific activity represented by that slice. It is a direct way to isolate and examine particular activities.
  • Color Customization: Users can change the color associated with protocols or other objects by clicking their labels in the list beside the chart. It enhances visual clarity and allows for personalized data representation.

Pie

Pie charts that display information by the production switch have an inner and outer ring, as shown in the following example.
Figure 2. Two-ring Pie Chart

For example, in the Tracked Hosts by Production Device & IF pie chart,

the detailed behavior of the pie charts in the Arista Analytics Fabric view, specifically those displaying information related to production switches, is shown. The key feature is the dual-ring structure:

  • Inner Ring: Represents a broader category, "Production Device" (switches).
  • Outer Ring: Provides a more granular breakdown, such as "Interface" (IF) details selected inner ring segment.

The interactive functionality is crucial, as clicking a segment in the inner ring filters the outer ring to display only the data relevant to that selected inner ring segment.

It allows for a hierarchical view of the data, enabling users to quickly drill down from a general overview (switch level) to specific details (interface level) within that overview. It is a good design for exploring relationships within the network data.

Selecting the Time Range

To restrict the current content to events occurring in a specific period, click and drag it to surround the area on a time visualization, such as the Flows Over Time.
Figure 3. Selecting the Time Range
To select the time range or to change the default refresh rate, click the Time Range control in the upper right corner. The system displays the following dashboard.
Figure 4. Time Range Control
This dialog provides the following options for setting the time range:
  • Quick: Simple settings, such as Today, Last 1 hour, etc.
  • Relative: Time offsets from a specific time, including the current time.
  • Absolute: Set a range based on date and time.
  • Recent: Provides a list of recently used ranges that you can reuse.
Select the range from the options provided, and the panels and displays update to reflect the new date and time range. To change the auto-refresh rate, click the Auto-refresh control. The system displays the following dashboard.
Figure 5. Change Auto Refresh Rate

Select the refresh interval from the options provided. Click Start to turn off the auto-refresh function.

Using the Search Field

The search field at the top of the dashboard filters the current displays by any text or numbers typed into the field.
Figure 6. Search Field
The green bars under the Search field show the currently applied filters. When the pointer is over a green bar, it displays icons thatcontrol the filter.
  • Enable/Disable filter
  • Pin/Unpin filter
  • Exclude/Include matches
  • Remove filter
  • Edit filter

The Action option in the upper right corner applies these actions to all the currently applied filters.

Click a segment on a pie chart for the appropriate filter; it automatically inserts into the Search field. To undo the filter, click the Remove filter icon.

To filter the information in the displays, enter the characters to filter the display in the search field. For example, for entering the first part of an IP address, it updates the displays to show only those IP addresses that match the characters entered. The following are some of the most helpful search filters:
  • IP address
  • Host name (requires DNS services)
  • Protocol, for example, HTTP, HTTPS, ICMP, and so forth
  • DMF interface name

To define complex queries using field names, which can be seen by scrolling and clicking on an event row. For example, on the sFlow®* dashboard, the query proto : TCP AND tags : ext displays all externally bound TCP traffic. OR NOT ( ) are also permitted in the expression. For more details about the supported search syntax, refer to the following URL:https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html#query-string-syntax.

Using Discover Mode

Select the Discover option in the left panel of the Analytics window; the system will display the following page.
Figure 7. Discover Mode

Use Discover mode to see the indices in the ElasticSearch database and identify the available data.

Search Performance Limitations

Refrain from executing general queries for a wide time range. For example, suppose you want to query for 7 or 30 days. In that case, do a specific query flow, filter interface, specific source or destination IP address, and specific source or port number as it eases the query load.

To query NetFlow or sFlow® for more extended periods, use the FLOW Dashboard to determine the trend and then do a specific query, such as querying a specific flow or time, on the Netflow or sFlow® dashboard.

Periodically monitor the AN Load Dashboard for index and query load and scale up the Analytics Node if the Load is Yellow/Red.

These recommendations aim to optimize query performance and prevent system overload, especially when dealing with large datasets and extended timeframes.

Managing Dashboards

Select the Dashboards option from the left panel on the Analytics window to manage Dashboards. The system displays the following page.
Figure 8. Dashboard Mode

Refer to the Kibana documentation for details about creating and managing dashboards.https://www.elastic.co/guide/en/kibana/8.15/index.html

Following are the best practices for managing dashboards and saved objects within Arista Analytics, focusing on organization, maintainability, and upgrade compatibility:

  • Consistent Naming Conventions: Employ a naming convention that aligns with your environment.
    • Use prefixes to categorize dashboard content (for example, "ARISTA").
    • Include descriptive terms in the dashboard name to specify its type.
    • It improves organization and simplifies selection.
  • Simplified Management: Consistent naming allows for easier individual selection and bulk operations.
    • Exporting dashboards based on their type facilitates tracking and management of modifications.
  • Upgrade Compatibility: Build dashboards using custom visualizations and searches created for your environment.
    • Avoid relying on default objects, which might change during upgrades, potentially breaking your dashboards.

In summary, the best practices advocate for a structured and organized approach to dashboard management, ensuring maintainability, traceability, and resilience to system upgrades.

Geographic Location

  • GeoIP Database: Arista Analytics uses the MaxMind GeoIP database to associate public network IP addresses with geographic locations.
  • Map Visualization: This association displays a heat map on the sFlow® dashboard.
  • Geographic Filtering: It filters the traffic shown on the map by selecting specific regions:
    • Square Tool: Draw a square to select a rectangular area.
    • Polygon Tool: Draw an irregular shape to select a more complex region.
    • Zoom and Detail: Selecting a region will zoom in on that area and provide more detailed information about the traffic flowing to or from it.
Figure 9. Geographic Flow Source and Destination

This process enables users to visually analyze network traffic patterns based on geographic location and focus on specific areas of interest for deeper investigation.

IP Addresses

This section describes identifying traffic transmitted or received by the source or destination IP address.

Source and Destination Addresses

Figure 10. Identifying Source and Destination IP Addresses
Click an IP address, then click the Magnifying Glass icon (+) to pin the address to the dashboard.
Figure 11. Filtering Results by IP Address

The selected IP address is added to the filters on the dashboard.

Each dashboard has a bar chart depicting traffic on the y-axis and time on the x-axis. To add a time filter, click and drag an area in the All Flows Over Time bar chart.

Interfaces Sending or Receiving Traffic

To identify specific interfaces that are sending or receiving traffic, select the following features:
  • DMF Top Filter interfaces
  • Production interfaces
Figure 12. DMF Filter Interfaces
Figure 13. sFlow® > Flow by Production Device & IF

This information derives from the LLDP/CDP exchange between the production and DANZ Monitoring Fabric switches.

Filter Interface Information

Add the filter interface name to the NetFlow dashboard to see hop-by-hop forwarding of flows for NetFlow traffic coming from the DMF Service Node for a specific flow. Arista Analytics then shows the filter interface name associated with that flow. It allows the network administrators to visualize the path a particular flow took through the network. If a flow goes through multiple hops, the dashboard would ideally display multiple "filter interface names," clearly indicating the sequence of interfaces.

Displaying Filter Interface Names

The nFlow by Filter Interface window on the NetFlow dashboard, shown later, can display the filter interface name where traffic is coming in for the NetFlow service. To display this information, enable the records-per-interface option in the NetFlow managed service configuration on the DANZ Monitoring Fabric Controller using the commands shown in the following example.
controller(config)# managed-service netflow-managed-service
controller(config-managed-srv)# service-action netflow netflow-delivery-int
controller(config-managed-srv-netflow)# collector 10.8.39.101 udp-port 2055 mtu 1500 records-per-interface
Figure 14. Production Network > NetFlow Dashboard with Filter Interface Name

NetFlow Managed Service Records-per-interface Option

The following example displays the running-config for this configuration.
! managed-service
managed-service netflow-managed-service
	service-interface switch 00:00:4c:76:25:f5:4b:80 ethernet4/3:4
	!
	service-action netflow netflow-delivery-int
		collector 10.8.39.101 udp-port 2055 mtu 1500 records-per-interface
controller(config)# sh running-config bigtap policy netflow-policy
! policy
policy netflow-policy
	action forward
	filter-interface filter-int-eth5
	use-managed-service netflow-managed-service sequence 1 use-service-delivery
	1 match any

After enabling this option, the nFlow by Filter Interface window, shown earlier, displays the filter interface identified in the policy that uses the NetFlow managed service.

The production device port connected to the filter interface sends LLDP messages; Arista Analytics also displays the production switch name and the production interface name attached to the filter interface in the nFlow by Production Switch & IF window.

In the example later, wan-tap-1 displays in the nFlow by Filter Interface window. The production device N1524-WAN and the interface Gi1/0/1, connected to filter interface wan-tap-1, are displayed in the nFlow by Production Switch & IF window.
Figure 15. Production Network > NetFlow Dashboard with Filter Interface Name
*sFlow® is a registered trademark of the Inmon Corp.
Arista Analytics
User Guide
Arista Networks

www.arista.com

Arista Analytics User Guide

Version 8.10
DOC-08910-01

 

Headquarters
5453 Great America Parkway
Santa Clara, CA 95054, USA
+1-408 547-5500
www.arista.com
Support
+1-408 547-5502
+1-866 476-0000
This email address is being protected from spambots. You need JavaScript enabled to view it.
Sales
+1-408 547-5501
+1-866 497-0000
This email address is being protected from spambots. You need JavaScript enabled to view it.
© Copyright 2026 Arista Networks, Inc. The information contained herein is subject to change without notice. Arista Networks and the Arista logo are trademarks of Arista Networks, Inc., in the United States and other countries. Other product or service names may be trademarks or service marks of others.