Segmentation in the Data Center With Arista CloudVision

Introduction

In this article, we will take a look at how network layer segmentation is achieved in a VXLAN BGP EVPN multisite architecture using Arista CloudVision.  For overviews of the primary technologies discussed in this article, please take a look at our VXLAN BGP EVPN primer and our segmentation primer.

Arista's Multi-Domain Segmentation Services, MSS, provides a centralized approach to macro and micro segmentation in the modern data center.  MSS defines micro and/or macro perimeters, known as MSS Groups, by defining endpoints and workloads by IP.  Administrators can then create security rules in CloudVision to explicitly forward or drop communications between these defined groups. These rules are then distributed to EOS-powered switches for enforcement at full line rate.  This process allows for granular, direct control over network traffic without requiring endpoint software agents or proprietary network hardware or protocols.

Lab

The lab topology consists of two interconnected data centers.  Both data centers are built on standard spine-leaf physical architecture, with open-standards-based VXLAN BGP EVPN running on top.  For simplicity, the two data centers are directly cabled to each other through their border gateways, providing multi-site communication.  Both Data Center 1 and Data Center 2 have only a single leaf.  Host to host connectivity is tested using Apple MacBook Pro laptops.

Equipment

Building a security policy

Creating and applying security policies in Arista CloudVision is a straightforward, five-step process.  CLI configurations associated with their CloudVision UI equivalents are shown below.  In addition to creating groups and rules manually, as outlined here, Arista also offers an automated manner to assess your traffic patterns and dynamically build the various policy components based on those findings.  This is the ZTX appliance/service.  For the purposes of this guide, the ZTX's configuration and functionality are omitted.

First, you will want to define your IP groups via the Groups tab in the Network Security Policy Manager section of CloudVision, located on the left-hand menu bar.  These are groups of hosts defined by IP prefix.  These IP prefixes can define an entire subnet or even individual hosts using the '/32' subnet mask.  Multiple IP prefixes can be added to a single IP Group.

Next, you will define the types of traffic you want to subject to enforcement via the Policy Objects tab, in the same Network Security Policy Manager section of CloudVision.  You will select the 'Add Object' button, followed by the 'Service' option.  There are two primary options when defining traffic: TCP/UDP and ICMP.  For lab purposes, we chose 'TCP/UDP' and subsequently 'TCP'. Next, you will define both source and destination ports.  Traditionally, with TCP flows, the source port will be left to 'all,' while the destination port will be that of the particular service you want to inspect.  For lab purposes, we defined port 22 (SSH) as the destination.  Multiple protocols/ports can be added to a single Service Group as required.

Third, you will create a Domain via the Domain tab in the same Network Security Policy Manager section.  A Domain is simply the collection of physical switches to which the various components of your security policies will be applied. Common groupings could be all of the switches in a particular data center, all of the switches in a multi-site/multi-data center topology, or all of the switches in a data center or multiple data centers on which a common VRF exists; e.g. all test-VRF switches, dev-VRF switches, or prod-VRF switches.  Please note that a switch can only belong to a single Domain.

Fourth, you will create a Rule via the Rules tab in the same Network Security Policy Manager section.  A Rule ties together the source and destination groups with the service group[s], and the action to take against traffic matching the service group.  Options include unidirectional or bidirectional, and standard and action type, including standard forward/drop.

Next, you will create a Policy via the Policy tab in the same Network Security Policy Manager section.  At a high level, a Policy is simply a collection of Rules.  Any given policy has three general components.  First, is the physical switch Domain to which the rules in the Policy will be applied.  Next is the VRF to which the rules will be applied. 

Lastly, once the Policy is created, you can begin to assign rules.   Preexisting rules can be added, but new rules can also be created from this view. 

Once your full policy definition is complete, you will deploy your newly created security policy to your fabric[s] via the Workspace submission and execution workflow in CloudVision.  This will push the necessary EOS configurations, seen above, to your host-facing leafs.

Testing

To demonstrate both macro and micro segmentation, two distinct test scenarios were built.  The definition of 'macro segmentation' can be somewhat subjective.  For the purposes of this lab, macro segmentation is simply defined as a security policy applied to the entirety of a network rather than a single host/IP or group of IPs within a given network.  Conversely, 'micro segmentation' will refer to a security policy used to segment hosts within a common network or broadcast domain. 

Macro segmentation

To demonstrate macro segmentation, two simple tests were performed.  The first was an intra-DC test where a MacBook Pro connected in DC1 was placed on VLAN10, while a second MacBook Pro was also connected in DC1 and placed on VLAN30.  The VLAN30 network was deployed in both DC1 and DC2.  The second test, while identical in SRC/DST networks, was performed across the Data Centers, showcasing the multi-site segmentation capabilities of Arista CloudVision.  Below, you can see the constructs that were built to perform these tests, following the process discussed earlier.

Despite the two networks under test being fully routable to one another on the ingress and egress leafs, we see failed connectivity between the hosts.  These tests were successful in blocking SSH (TCP 22) traffic between networks both intra and inter data center using a macro segmentation architecture in Arista CloudVision.

Micro segmentation

To demonstrate micro segmentation, an intra-DC test scenario was built. A MacBook Pro in DC1 was placed on VLAN10, while a second MacBook Pro in DC1 was also placed on VLAN10.  Additional IP Groups were built in CloudVision's Policy Manager, defining each of the test MacBook Pros as /32 hosts.  Please note that while not demonstrated, micro segmentation is fully functional across data centers in a multi-site topology.  Below, you can see the constructs that were built to perform these tests, following the process discussed earlier.  Domain and SSH service configurations have been omitted as they are identical to the previous macro segmentation test scenario.

While the two test VMs sit on the same network and are thus, Layer 2 adjacent, we see failed connectivity between them.  SSH (TCP 22) traffic between the hosts was successfully blocked using a micro segmentation architecture in Arista CloudVision.

Conclusions

Creating and deploying Multi-Domain Segmentation Service, or MSS, policies in Arista CloudVision is a straightforward and clear process.  The Policy Manager configuration area within the broader Network Security section of CloudVision cleanly presents the various components required to build segmentation policies.  The grouping of physical switches into a domain is akin to defining a logical switch in a virtual environment.  This outlines the physical boundaries of your segmentation policies.  Defining IP groups by individual host IPs or as whole subnets is a simple process, requiring only a few clicks.  You then configure your protocols in a similar fashion before referencing those protocols in a rule alongside a forward or drop action.  Finally, you create a policy that is a collection of rules paired with your physical domain and target VRF.

The Policy Manager section in the CloudVision UI is clean and simple, allowing users to easily create and manage both macro and micro segmentation policies. Interoperability across policy-aware fabrics is fully supported. This ensures consistent policy deployment in both single-fabric or multi-fabric environments.

Arista's MSS sets itself apart from other network layer segmentation solutions by not directly applying tags to traffic sources or destinations.  In solutions where a host IP can only receive a single tag, a user may need to duplicate any rules applied to that host IP's entire subnet, but just for that single IP.  This is due to the host IP receiving a more specific tag than that assigned to its whole subnet.  This does not apply to MSS due to it not directly using traffic tags, but rather assessing SRC/DST IPs directly based on the groups to which they belong.  MSS also provides the ability to [re]order individual rules in an overall policy to be assessed in a top-down manner similar to a traditional firewall.  This allows for segmentation exceptions such a single host IP in Subnet A being allowed to SSH to hosts in Subnet B, while the remainder of Subnet A is prevented from SSH to Subnet B.

For organizations looking to enhance security and operational efficiency in their data centers through network segmentation, Arista's Multi-Domain Segmentation Service is a scalable and dynamic first step.

How WWT Can Help

Now that we understand how Arista's Multi-Domain Segmentation Service, or MSS, as configured in CloudVision's Policy Manager, can be leveraged to define and instantiate segmentation policies in the data center, it's time to put that knowledge to work.  World Wide Technology (WWT) is the premier resource for helping customers design and build their modern data centers. With decades of experience in data center networking and modern security initiatives, WWT has a unique combination of expertise, OEM relationships, and hands-on learning opportunities.  The Labs and Learning Paths on our digital platform can help you gain tangible experience with these technologies, while WWT Research can further provide real-world use cases and white papers from customers we have helped along their IT transformation journeys.  If you are interested in a more customized, purpose-built lab environment, our world-renowned technology proving ground, the Advanced Technology Center, is the place to do it.

Reach out to your WWT Account Team or contact us to learn more about how WWT can support your organization with your infrastructure modernization journey.