Perform the following configuration steps to prepare the devices for MSS using the CLI. Several configuration steps are required on all supported platforms, while others are unique to specific SKUs.

Refer to the specific Strata and Sand sections for SKU-specific configuration information.

For the devices to be able to stream to CVP and receive information from CVP, enable gRPC Network Management Interface (gNMI) on the devices:

ld459.12:57:58(config)# management api gnmi
ld459.12:58:13(config-mgmt-api-gnmi)# transport grpc default
ld459.12:58:20(config-gnmi-transport-default)# no shutdown

If the management is in a user-defined vrf, for example vrf mgmt tenable gNMI in that user-defined vrf.

ld459.12:59:16(config)# management api gnmi
ld459.12:59:18(config-mgmt-api-gnmi)# transport grpc default
ld459.12:59:25(config-gnmi-transport-default)# vrf mgmt
ld459.12:59:40(config-gnmi-transport-default)# no shutdown

For devices to receive dynamic group information from CVP, enter the following parameters at the end ofthe TerminAttr configuration:

ld459.13:00:28(config)# daemon TerminAttr
ld459.13:00:29(config-daemon-TerminAttr)# exec /usr/bin/TerminAttr -smashexcludes=ale,flexCounter,hardware,
kni,pulse,strata -cvaddr=10.248.18.240:9910,10.248.18.241:9910,10.248.18.242:9910 -cvauth=token,/tmp/token
-cvvrf=default -taillogs -cvtargetconfigs arista/traffic-policy
! New daemon configuration will only take effect after restarting the daemon by doing 'shutdown/no shutdown'.
ld459.13:00:39(config-daemon-TerminAttr)# no shutdown

The ZTX appliance is managed primarily through CloudVision's MSS Service Studio once the device has been onboarded and bootstrapped with configuration pushed through the Static Configuration Studio. Device onboarding is described by the following Device Onboarding instructions. Since MSS Service will manage the device at runtime, this configuration section will primarily focus on the necessary bootstrap configuration that is pushed through Static Configlets Studio. Configuration pushed through MSS Service can also be validated.

Static Configuration Studio can be leveraged to build the initial configurations on the ZTX node and include provisioning loopback, ethernet and port-channel interface and IP connectivity to other devices in the network. Additional details about Static Configlet Studios are available on the Arista CloudVision Help Center Static Configuration Studio site.

Ports from the ZTX device used as uplinks to the MLAG Service TOR should all be members of a single port-channel to achieve maximum throughput with the service TOR. A loopback interface is needed to act as the GRE tunnel endpoint to terminate mirrored packets. The following is a sample configuration that can be pushed from Static Configuration Studio to bootstrap the device so that it can be managed by MSS Service.

ZTX# show running-config
!
! Port-Channel with member ports connected to MLAG Service TOR.
! MLAG service TOR peers should have an IP address in the same network
interface Port-Channel1
no switchport
ip address 10.10.250.1/24
!
interface Ethernet1/1
speed forced 10000full
no switchport
channel-group 1 mode active
!
interface Ethernet1/2
speed forced 10000full
no switchport
channel-group 1 mode active
!
! Loopback Interface used as GRE tunnel endpoint.
interface Loopback0
ip address 10.10.254.1/32
!
! Default static route for reachability of GRE mirror source
ip route 0.0.0.0/0 10.10.250.2

Use the MSS Service to configure the ZTX device and the mirroring session on the MSS TOR. The following section describes the configuration that MSS Service will push and how the configurations contribute to the overall solution, aside from show commands for debugging the user is not expected to actively manage the ZTX device after the onboarding and bootstrap stage are complete.

The following configuration puts the ZTX device into monitor mode.

ZTX# show running-config
!
firewall distributed instance
mode monitor
no disabled
!

The following configuration exports the flows observed by the monitoring device to CV using IPFIX as the transport. Note that TA is acting as IPFIX collector listening on 127.0.0.1 for IPFIX records and then streaming that data to CV for ingest to provide telemetry and policy recommendations.

ZTX# show running-config
!
flow tracking firewall distributed
tracker flowtrkr
exporter exp
collector 127.0.0.1
local interface Loopback0
no shutdown
!

Tunnels are configured to terminate each GRE tunnel created from a TOR’s monitor sessions, and flow tracker is enabled on all the tunnels. The tunnel source is always set to the IP address of the loopback interface created during the bootstrap process The tunnel destination corresponds to the GRE tunnel endpoint of the TOR that originated the mirror session. Note that mirrored traffic terminated at the ZTX device and is always dropped so the reverse GRE tunnel is never utilized.

ZTX# show running-config
!
interface Tunnel0
flow tracker firewall distributed flowtrkr
tunnel mode gre
tunnel source 10.10.254.1
tunnel destination 10.10.254.2
!

Deploying the ZTX Monitor Node in an Arista Network

This chapter describes how the ZTX can be physically and logically inserted in an Arista network and provides reference configuration examples.

IP Communication Requirements

As represented in the following logical diagram, there are two fundamental IP communication requirements for the ZTX Traffic Mapper:

The ZTX requires bidirectional IP communication with Arista Cloud Vision instance, using the out-of-band management interface, in order to: export traffic metadata in IPFIX format. receive provisioning settings over HTTP. It also requires bidirectional IP communication over the in-band interfaces with the Arista switches that compose an MSS Security Domain, in order to: receive monitored traffic from the switches over L2oGRE. maintain the healthiness of L2oGRE tunnels.

In-band Connectivity Requirements

The ZTX Monitor Node throughput is used for extracting and exporting communication session metadata from mirrored traffic received by the switches that compose one - and one only - Security Domain. The traffic received by the ZTX consists of a copy (mirror) of the original layer-2 traffic packets that match one or more monitor rules, truncated to the first 256 or 192 bytes¹ and embedded into a L2GRE envelope, which adds 24 bytes of overhead.

Centralized Configuration

 

• Centralized: The ZTX is placed within a service pod and its interfaces are physically connected to a pair of switches that have IP connectivity to the Security Domain.

  This option is based on the best practice of using a dedicated self-contained unit in the network to provide all required network services with optimal scalability, efficiency and simplicity.

  With this approach, the planned network throughput of the service pod, needs to account for the theoretical inbound capacity of the ZTX, unless further rate limiters are applied in the data path from the Security Domain.

The physical links of the ZTX that connect to the same physical device or, in case the peer devices use multi-chassis link aggregation, to the same device pair, can be grouped in a port channel. This choice may depend also on the selected routing design, which is discussed next.

Once the ZTX device has been onboarded to CloudVision and the in-band communication with the Security Domain is complete, the next step is to associate it with a MSS Monitor Object in CloudVision, so it can be referenced by one or more policy rules.

An MSS Monitor Object is a structure that defines how a ZTX device can communicate with a Security Domain.

The definition of a Monitor Object is possible from the MSS Service, which, once enabled in General Settings, is available under Network Services in the Studios pane, as shown in the screenshot below.

As for any other studio, before making any edit to the MSS objects, a change-control workspace needs to be created, as shown in the following image.

The studio form presents most of the MSS objects structured in a multi-level tabular format. Monitor Objects are listed in a dedicated table in the bottom portion of the studio. A new object can be defined using Add Monitor Object, as shown in the following image:

Parameter	Description	Recommended Value
Name	Unique string identifying the Monitor Object that can be referenced by a policy rule
Monitor Node	Associated ZTX device among those present in the device inventory
Exporter Interface	Interface name on the ZTX that is used as IPFIX exporter and L2GRE tunnel termination
Active Timeout	Active timeout period in ms for exporting IPFIX reports	long-term setting: 30000 – 300000 ms   temporarily for initial deployment: 3000 - 30000 ms
Tunnel Destination IP	IP address of the ZTX used as L2GRE tunnel destination on switches part of the Security Domain
Tunnel Source Interface	The interface name on the Security Domain switches is used as an L2GRE tunnel source. Note: All switches consistently use the same interface name. Important: Tunnel Source Interface IP should be unique to each TOR. In the MLAG deployment scenario, specify the Tunnel Source Interface IP unique to each MLAG peer device rather than specifying interfaces with shared IP addresses.
Truncation	Boolean field, indicating if mirrored traffic is truncated or not	Yes
Rate Limit	Rate limiter expressed in Mbps applied on Security Domain switches to mirrored traffic per VRF sent to the ZTX	10,000

Once a new Monitor Object entry has been populated with all required values, it is possible to select it inside the field Monitor Name in multiple policy rules part of the same policy.

The same Monitor Object can be concurrently referred to by multiple policies, while a policy (associated to a security zone) can only use one Monitor Object.

First, it is necessary to navigate in the studio form to the Policies table, and from there, by clicking on the desired policy entry in the Rules column, it is possible to view and edit the corresponding policy rules. The following two images are provided as a reference.

Once a new Monitor Object entry has been created, it is necessary to validate its parameters by clicking on Autofill on the studio form, as shown in the following image:

If no errors are reported, the change-control workspace can be reviewed, using Review Workspace, and subsequently executed, following the same workflow used by other studios.