• 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.

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.

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

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.

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.

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.

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

(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

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 0.0.0.0/0) and specify segment-policies between this default segment and other defined segments.