Arista Analytics Basic Operations

This chapter describes how to use Arista Analytics to monitor and analyze traffic and events in the monitoring fabric and the DANZ Monitoring Fabric controller. This chapter includes the following sections:

Overview

Arista Analytics provides a non-proprietary extensible UI that integrates DMF Recorder Nodes, DMF Service Nodes, and the DANZ Monitoring Fabric controlled using an SDN Controller. The system has an extensive library of visualization components and analytics to compose new dashboards and answer further questions as they arise. The Arista Analytics node/cluster answers questions that would otherwise require specialized applications, such as Application Data Management (ADM) or Intrusion Protection Management (IPM). The Analytics node/cluster creates a document for each packet received and adds metadata regarding the context, including the time and the receiving interface, which ElasticSearch can use to search the resulting documents quickly and efficiently.

Flows Dashboard

The Flows dashboard is displayed when accessing Arista Analytics, as shown in the following figure.
Figure 1. Production Network > Flows Dashboard
The left panel provides the following options to access Arista Analytics features:
  • Fabric: The home page for Analytics provides a series of tabs and sub tabs.
  • Controller: Opens the DANZ Monitoring Fabric GUI on the controller identified using the System > DMF controller option.
  • Discover: Use predefined indices to filter and display specific events.
  • Visualize: Customize the graphics displays provided by Arista Analytics.
  • Dashboard: Displays dashboards for DANZ Monitoring Fabric events.
  • Timelion: Display events and other results according to time series.

Based on ElasticSearch, the Analytics GUI and most of its features and operations are documented in the Kibana documentation, available at the following URL:

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

Kibana 7.2 is the version used for Arista Analytics version 7.3.

Arista Analytics Fabric View

The Arista Analytics Fabric View displays in the following three tabs:
  • Production Network: View information about the production network.
  • DMF Network: View information about the monitoring network.
  • System: Manage system configuration settings.

Each page contains panels with different functions and features. The network panels provide visualizations, such as pie charts, line graphs, or other graphic displays that reflect the current dashboard contents based on the specified query. The bottom panel lists all the events that match the current query. A pop-up window provides additional details about the selection when mousing over a panel.

Using Two-ring (by Production Switch) Pie Charts

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

When a second ring appears in a pie chart, click on any segment in the inner ring, and the outer ring provides a summary of information about the selected segment.

For example, in the Tracked Hosts by Production Device & IF pie chart above, the outer ring shows hosts tracked on each interface, while the inner ring summarizes the tracked hosts on each switch. Clicking on a segment for a specific switch on the inner ring filters the outer ring to show the tracked hosts for the interfaces on the selected switch.

Filtering Information on a Dashboard

Filter the events displayed on a dashboard by dragging the mouse cursor around an area on the dashboard. This action limits the information displayed on the dashboard to events similar to those selected. Click on any pie chart slice to limit the display to the specific activity chosen. To change the color assigned to a specific protocol or other object, click the label on the list to the right of the chart.

Selecting the Time Range

To restrict the current content to events occurring in a specific time period, click the mouse 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, and so forth.
  • 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 disable the auto-refresh function.

Using the Search Field

The search field at the top of the dashboard lets you filter the current displays by any text or numbers that you type into the field.
Figure 6. Search Field
The green bars under the Search field show the currently applied filters. When you mouse over a green bar, a series of icons are displayed that let you control 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.

When you click a segment on a pie chart, the appropriate filter is automatically inserted 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, if you enter the first part of an IP address, the displays will be updated to show only those IP addresses that match the characters entered. The following are some of the most useful search filters:
  • IP address
  • Host name (requires DNS services)
  • Protocol, for example HTTP, HTTPS, ICMP, and so forth
  • DMF interface name

You can 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.

Search Performance Limitations

Do not execute a general query for 7 or 30 days. A 7 or 30 day query should be used with specific criteria, like querying a specific flow, filter interface, or DNS server.

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

If you have a great deal of NetFlow traffic, use one Analytics node only for NetFlow and another node for other Analytics traffic.

Using Discover Mode

When you select the Discover option in the left panel of the Analytics window, the system displays the following page.
Figure 7. Discover Mode

You can use Discover mode to see the indices available in the ElasticSearch database, and to identify the kind of data that is available.

Managing Dashboards

To manage dashboards, select the Dashboards option from the left panel on the Analytics window. 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/7.13/index.html
Note: Recommended Best Practices - While creating a dashboard or any saved objects, use the naming convention that suits your environment. For example, use a prefix to identify the content of the dashboard, and then use the body of the dashboard name to identify the type of dashboard. For instance, in the above screenshots, we used a naming pattern, prefixed with “ARISTA” and specifying Type: dashboard allows a manageable set of things to individually appear to click or select all. Furthermore, exporting dashboards individually based on their type is a more appropriate option as modifications to a dashboard can be better tracked by this method. To reduce the potential for conflict in upgrades, your dashboards should use only visualizations and searches that you create; do not depend on default objects that might change in the upgrade.

Custom Dashboards

User can add or insert their own custom dashboard. select the Dashboards option from the left panel on the Analytics window. The system displays the following page, which is the default dashboard:

Figure 9. Default Dashboard Mode
In the default dashboard, user can select the option, which one to customize as per their requirement.
Figure 10. Search for Dashboard
For the customization of the option on the dashboard, copy its ID as following.
Figure 11. Select the option and copy the ID
Note: ID has to be inserted into the dashboard exactly the same as captured from the bar to work.
Figure 12. Setting custom Dashboard
Figure 13. Default Dashboard configuration
Open the menu to select the action.
Figure 14. Open the action menu
You can select the tab for the duplicate entries.
Figure 15. Duplicate the tab
Figure 16. Insert the name tag ID
Now the dashboard shows the customization of the option selected by the user.
Figure 17. Selected option for the user

Mapping IP Address Blocks

You can map an IP address or a range of addresses to a description, which lets you search for description text instead of the IP address. This lets you identify a specific group or organization that is sending or receiving traffic.

To assign a single IP address or a block if IP addresses to a tool, group, or organization, complete the following steps.

  1. Select System > Configuration and click the Edit control to the left of the IP Block section.
    Figure 18. 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 list of blocks and will be 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 19. Key Value Pairs
    The first four keys are copied automatically. 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), which is 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 enclosed in double quotation marks (“”).
  5. (Optional) To define an additional key, select any key and select Duplicate from the pop-up menu. Then type over the existing value with the correct value for the new key.

    The default keys are used in existing dashboards. The added key pairs can be used in customized dashboards. The fifth and sixth keys can be custom keys.

    These keys are added to the flow for the source and destination IPv4 address. For example, source description would be sDesc and destination description would be dDesc.
    Note: Be careful to match values in the same order as the corresponding key positions.

Mapping DHCP to OS

The user can map DHCP signatures to known operating systems. These unique signatures are derived from fingerbank.org. As shown in the following image, a number of two-digit numbers are assumed signatures of each OS (derived from fingerbank.org).
Figure 20. Unique OS Signatures from fingerbank.org
Figure 21. OS Information Received through DHCP Signatures

Mapping Ports and Protocols

The Analytics Node maps typically used ports to their L4 applications. The same is done for protocols. These protocols and ports can also be user-defined for custom application ports and custom protocols.
Figure 22. Edit Ports
Figure 23. Edit Protocols

SNMP Collector

SNMP collectors facilitate third party NetFlow/IPFIX sources. The Analytics Node supports both SNMPv2 and SNMPv3.
Figure 24. SNMP Collector

Mapping OUI to Hardware

The user can map ARP Organizational Unique Identifiers (OUIs) for various hardware vendors.
Figure 25. OUIs of Various Hardware Vendors

Topic Indexer on Arista Analytics

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 fieldnames and specifying the supported timestamp field during the ingestion phase. The renaming of fieldnames 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 26. Analytics > Fabric
  • Another view:
    Figure 27. System > Analytics Configuration
  • The configuration for a topic to be consumed can be specified as described in the design section.
  • Figure 28. Node selection

Configuration

Kibana Configuration
  • To perform the topic_indexer configuration, select the System > Configuration > Fabric page and open the Analytics Configuration panel:
    Figure 29. System > Configuration
  • Figure 30. Topic indexer configuration

Field Details

Each topic is mapped 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. We create it as topic_name + index_name. Setting this field will be particularly useful when ingesting multi-partitioned topics from the client's end.
  • index: A dedicated index name we want for the topic; type string. In Elastic Search (ES), it will be 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.

    Specifies format for modifications to incoming data.

  • type: This is to set timestamp-field as the type.
  • source_key: This is the source field name in the incoming data.
  • indexed_key: This is the destination field name inserted in the outgoing ES index.

    The indexed_key may be a @timestamp field of an ES index. If we do not specify a @timestamp field, topic_indexer automatically picks the time the message was received 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. In topic-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 an invalid field text.
Note: These conventions are valid for all other input types as well.

Some 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.
  • While entering the broker address, use 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. You must reapply them after any restart of AN.
Use Case:
  • Cross-index visualization - two data streams that need cross-querying:
  • Figure 31. 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 32. Discover dashboard
  • Step 3. Create a common field (runtime field) between the two data streams by applying an API in Dev Tools.
    Figure 33. 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. You must reapply them after any restart of AN.
  • Step 4. Finally, create a visualization using this common field, for example, Customer. The illustration below shows the Top 5 customers with the highest spending across products and services.
    Figure 34. 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

Below are some of the commonly known issues and their troubleshooting scenarios:
  1. The Save button in 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 when filling in the config for topic indexer as stated in the above section linked: Topic Indexer on Arista Analytics . As illustrated below, you may encounter validation errors when entering an invalid value in the configuration field. Topic Indexer on Arista Analytics
    Figure 35. 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. Index for topic indexer is not 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 name of the index is prefixed by topic_indexer_.

    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 once again to see whether the spellings for 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 in the configuration. For more details, please review the following links:
      1. Kafka 3.5 Documentation
      2. Kafka Listeners – Explained | Confluent
    3. If all the above steps are correct, you should now check the logs in the Analytics Node for the topic indexer.
      Steps to reach the topic_indexer.log file in 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 into 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 above), use the topic_indexer log file to validate the problem.

  5. Index pattern for topic indexer is missing.

    In the Kibana UI, we create 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:

    Create an index pattern | Kibana Guide [7.17] | Elastic