The configuration guide is no longer being updated. Please refer to the CloudVision Help Center going forward.

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.