MSS-G with Dynamic Configuration from Forescout

Using Forescout, an MSS-G configuration can be pushed automatically to CloudVision. This section covers the use of Forescout eyeSegment for policy definition and eyeSight for segment assignment. These systems produce an MSS-G configuration that is dynamic, and while visible on CloudVision, it bypasses the CLI on switches and will therefore not show up in the device running config.

There are two integration points from Forescout into Arista MSS-G:
  • host to segment mapping in the Forescout console’s Policy Manager
  • segment policy definition in Forescout eyeSegment

Both integration points are described below. Before deploying this integration, note that there is a terminology overlap:

  • Arista MSS-G uses the terms “group” and “segment” interchangeably.
  • The segments defined in the Forescout console under Tools > Segment Manager are static ranges designed to indicate areas of the network managed by Forescout and are unrelated to Arista MSS-G segments.
  • The groups defined in the Forescout console Policy Manager are for organizing host/user/device taxonomy.Although it is possible through the Forescout Policy Manager to map each Forescout Group to an Arista MSS-G group, it is neither automatic nor required. In the majority of use cases, Forescout Groups will be hierarchical and not map directly to Arista MSS-G groups; instead, Arista MSS-G groups will be defined by Forescout Policies that may consider hosts/users/devices across several Forescout Groups.


To configure MSS-G with Dynamic Configuration from Forescout the system must meet the following requirements:

On the Arista side:
  • EOS 4.27.1F+
  • TerminAttr 1.22+
  • CloudVision 2022.1.1+.
  • On the Forescout side it’s GA for Continuum 8.4.0, eyeSegment 5.18.0 (recommend 5.19.0), and the Forescout Arista MSS-G 1.0.0 module.

On the Forescout side:

  • Continuum 8.4.0
  • eyeSegment 5.18.0 (recommend 5.19.0)
  • Forescout Arista MSS-G 1.0.0 module.


Note the following limitations before configuring MSS-G with Dynamic Configuration from Forescout.

  • Port matching: Policies are enforced based on IP address, and at this time there is no support for port or protocol matching.
  • 60-segment limit: Arista CloudVision and EOS switches support a maximum of 60 segments.
  • Single segmentation domain: All EOS switches participating in MSS-G receive all host-to-segment assignments transmitted from Forescout eyeSight to Arista CloudVision.
  • Single VRF: The integration supports just a single Virtual Routing and Forwarding instance, or VRF. That VRF is configurable, but by default it uses the default VRF.
  • Initial sync time: The initial transmission of host-to-segment assignments from CounterACT to CloudVision could take up to an hour, depending on the number of hosts, the number of CounterACT appliances, and the latency between CounterACT and CloudVision. It can be made much faster by enabling dynamic configuration on participating switches after CloudVision has received all initial segmentation configuration.
  • Host scale: The integration supports up to 25,000 hosts in its initial phase. Enforcement point scale: The integration supports up to 100 enforcement points. Note that not all switches must be used as enforcement points. As long as traffic flows through an MSS-G capable enforcement point, policies will be enforced.
  • Supported actions: Currently, the supported actions are forward and drop.
  • IPv6: IPv6 is not currently supported in this integration.
  • Wifi endpoints: To make the integration work with wireless clients, access points must be configured to forward traffic in the clear to an enforcement point.

Deployment Guidelines

  • Subnets: eyeSight applies policies to single hosts, but users may assign all hosts within a subnet to a single segment using CloudVision Studios.
  • Default forwarding behavior: Policies are enforced based on destination address. There are three cases.
    • The source and destination address each belong to a segment, and there is a segment-policy defined that determines the forwarding behavior for the packet. In this case, participating switches will enforce the configured segment policy.
    • The destination address does not belong to any segment. In this case, there is no MSS-G configuration to enforce, and the switch’s actions will reflect whatever non-MSS-G configuration exists on the switch.
    • The destination address belongs to a segment, but either the source address does not or there is no segment policy to determine what action the switch should take. In this case the switch uses an “unspecified policy action” default, which could be DROP or FORWARD. This can be set in the eyeSegment MSS-G plugin.
  • One segment per host: A host IP address can exist in only one Arista segment (e.g., an IT admin user cannot be in both a “user” and an “admin” segment simultaneously).
  • Flat segment-policy hierarchy: eyeSegment policies destined for export to Arista CloudVision must not contain exceptions or make use of the “Any” group, eyeSegment virtual zones (e.g., Internal), or deleted zones. Improperly formed policies won’t be exported.
  • Bidirectional segment policies: Users should typically construct policies to forward or drop traffic in mirrored fashion (e.g., Zone A to Zone B Allow All and Zone B to Zone A Allow All). It is not strictly necessary to define rules both ways, but given the probability of bidirectional traffic, users will usually want to configure policies bidirectionally.
  • Export to CloudVision: The export to CloudVision is disabled by default until eyeSegment version 5.19, but can be enabled via the fstool command. Starting with version 5.19 it is enabled by default.
  • Resynchronization: Users must configure resynchronization per host-to-segment assignment policy or else CounterACT will never transmit host-to-segment assignments for hosts it learns while its connection to CloudVision is down. All deployments should use resync. Instructions for setting up resync can be found in the policy template.
  • Policy export flap: Exporting policies from eyeSegment to MSS-G may result in a brief period of forwarding disruption as switches remove and then re-apply policies.
  • Switch forwarding table partition: The EOS switches must have forwarding table partitions in place that allow for the desired host scale.
  • A CloudVision certificate should be imported into Forescout Continuum’s trusted certificates in order to secure the connection between Forescout Continuum and CloudVision.
  • On 4GB switches there may not be sufficient memory to run dynamic MSS-G and sFlow.

Install the Arista MSS-G Module

Forescout’s Arista MSS-G module adds the ability to connect to CloudVision and also assigns MSS-G segment ID in the policy manager.

The MSS-G module is an *.fpi file just like any other Forescout module.

Figure 1. Forescout MSS-G Module

Once installed, double-click on the Arista MSS-G module from the list and enter the CloudVision information:

Figure 2. Forescout - Arista MSS-G Plug-in

Specify Group Assignments with Forescout Policy Manager

The Forescout Policy Manager can be used to assign a user/host/device to an Arista MSS-G segment. This function is available as an action inside any Forescout policy. The conditions for classifying an endpoint to a group within the Forescout policy manager can be advanced combinations of many pieces of data, including DHCP vendor class, DNS event, SNMP system uptime, OS version, Active Directory group, and many other factors. In the example below, other policies (not shown) have classified cameras into the “IOT-Camera'' Forescout group.

In the following example, another policy is defined that assigns the Arista Segment ID of “IOT-Camera” to all the members of the Forescout “IOT-Camera” group. Note that although the example shows a matching Forescout group and Arista MSS-G segment name, this is not required. However, if groups are defined on Forescout and segment policies are defined on CloudVision, then it is mandatory to have matching names.

Note: Group names configured on Forescout should not contain spaces.
Figure 3. Defining a Segment Policy

Define segment policies in eyeSegment

The Forescout eyeSegment interface can be used to define Arista MSS-G Segment policies. The Zones listed in each eyeSegment policy must match with Arista MSS-G group names being used by Forescout Policy Manager or CloudVision to map IP addresses to groups. Forescout eyeSegment policies that are to be exported to CloudVision must use “All” in the services field.

Figure 4. Exporting eyeSegment policies into CloudVision

Select Export to Arista MSS-G to export eyeSegment policies into CloudVision. Check that the appropriate segment-policies show up in CloudVision’s network-wide Network Segmentation view. All Forescout eyeSegment policies must be exported at the same time. If a subset of policies is exported, previously exported eyeSegment policies not currently selected will be removed.

Enable OpenConfig on Arista switches

On participating, segmentation-enabled Arista devices, enable OpenConfig with the following commands:

(config)#management api gnmi
(config-mgmt-api-gnmi)#transport grpc default
(config-gnmi-transport-default)#no shutdown

Enable Dynamic Configuration on Arista switches

Add the flag -cvconfig=true to the TerminAttr configuration on each participating switch:

(config)#daemon TerminAttr
(config-daemon-TerminAttr)#exec /usr/bin/TerminAttr -ingestgrpcurl=<address>:<port> -cvcompression=gzip -ingestauth=token,/tmp/token … -cvconfig=true
(config-daemon-TerminAttr)#no shut

Forescout with Studios

You may add a segmentation configuration via both CVP Studios and Forescout, if desired. However, the configuration should be non-overlapping.

One use-case is defining default policies. Forescout allows you to associate known hosts with segments, and will push segment-policies to CloudVision. However, it does not provide you a way to describe the desired forwarding behavior for unknown hosts. This may be important if, for example, you want to define the desired forwarding behavior between known hosts in the network and the Internet. In this case, you may define a segment with an IP prefix that captures the desired set of unknown hosts (possibly and specify segment-policies between this default segment and other defined segments.