Introduction

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

Cisco's scalable and efficient approach to data center segmentation leverages reserved fields in the VXLAN header.  By doing this, there is no need for proprietary encapsulations or packet manipulation; all enforcement is executed using open standards.  Group Policy IDs, or GPIDs, are defined in the VXLAN header based on various attributes configured in the Nexus Dashboard UI, including host IP or network addresses, VLAN IDs, or virtual machine tags.  These security IDs or tags, along with permit/deny contracts are pushed to the fabric for enforcement at the network level before this traffic ever leaves a data center rack.  

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.  Data Center 1 has a pair of vPC leafs, while Data Center 2 only has a single leaf.  This was done to provide flexibility when testing various scenarios.  Host to host connectivity is tested using Ubuntu VMs, running on a multi-homed Cisco UCS server.

Equipment

COMPONENTFUNCTION
7x Cisco Nexus 93180YC-FX3Network
Cisco UCS C220-M5Compute
Nexus Dashboard 3.2.1Orchestration
5x Ubuntu 22.04.5 LTS Test PCsHosts

Building a security policy

Creating and applying security policies in the Nexus Dashboard is a straightforward, five-step process.  CLI configurations associated with their Nexus Dashboard UI equivalents are shown below.

First, you will want to define your security groups via the Groups tab in the Security section of your fabric in Nexus Dashboard.  These are groups of hosts defined by IP subnet, VLAN ID, of VM attributes/tags.  Multiple groups of hosts can be added to a single Security Group.

Group Definition

Next, you will define the types of traffic you want to subject to enforcement via the Protocol tab in the Security section of your fabric in the Nexus Dashboard.  There are a ton of options when defining traffic, including IPv4 or IPv6 traffic types, 100s of protocols including TCP/UDP, and user-defined SRC/DST ports.  Multiple protocols/ports can be added to a single Protocol group as required.

Protocol Definition

Third, you will create a contract via the Contracts tab in the Security section of your fabric in the Nexus Dashboard.  A contract is simply the definition of what action you will take against traffic, matching the protocol you previously configured.  Options include unidirectional or bidirectional and standard permit/deny.  Depending on your segmentation requirements, a contract may consist of a single permit/deny rule or many.

Contract Definition

Fourth, you will put all of the pieces together via the Associations tab in the Security section of your fabric in the Nexus Dashboard.  In this step, you will select the VRF in which your SRC/DST groups exist, the groups themselves (in our example, the DST group is 'any'), and the contract defining the traffic and the action taken against it.  

Association Definition

Finally, you will deploy your newly created security policy to your fabric.  This will push the necessary NX-OS configurations 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 VM in DC1 was placed on VLAN2301, while another test VM in DC1 was placed on VLAN2303, a network 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 Nexus Dashboard.  Below, you can see the constructs that were built to perform these tests, following the process discussed earlier.

Group definition for Network 1
Group definition for Network 2
Protocol definitions
Fully configured contract

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 Nexus Dashboard.

Successful SSH connection prior to policy deployment
Failed SSH connection after policy deployment

 

Micro segmentation

To demonstrate micro segmentation, an intra-DC test scenario was built. A VM in DC1 was placed on VLAN2301, while a second VM in DC1 was also placed on VLAN2301.  Additional Security Groups were built in the Nexus Dashboard, defining each of the test VMs 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.  

Group definition for test VM1
Group definition for test VM2
Protocol definitions
Fully configured contract

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 Nexus Dashboard.

Successful SSH connection prior to policy deployment
Failed SSH connection after policy deployment

 

Conclusions

Creating and deploying data center segmentation policies is smooth and straightforward in Nexus Dashboard. Its clean UI and scalable workflows make it a solid choice for operating modern data centers. Defining security groups by IP addresses, VM attributes, or VLAN IDs is a clear process, requiring only a few clicks.  You then define your protocols in a similar fashion before calling those protocols in a contract with a deny or permit statement attached.  Finally, you put the pieces together in an Association, stating your source group, destination group, and contract (what traffic is permitted or denied).

The Security section in the UI is clean and comprehensive, 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 across diverse infrastructures, in both single-fabric or multi-fabric environments. For users with previous Cisco ACI experience, the constructs and logic in Nexus Dashboard's segmentation features will be familiar.  This should provide current ACI customers with an easily navigated path to an open standard VXLAN architecture, while maintaining their current segmentation needs.

While scaling policies across multi-fabric topologies may present a learning curve for new users, Nexus Dashboard strikes a healthy balance between powerful capabilities and operational simplicity. This makes it a valuable orchestration platform for organizations looking to streamline and optimize their segmentation strategies.

For organizations looking to enhance security and operational efficiency in their data centers through network segmentation, Cisco's Nexus Dashboard is a solid step in the right direction.

How WWT Can Help

Now that we understand how Cisco's Nexus Dashboard 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.

Contact your WWT Account Team or us to learn more about how WWT can support your organization on its infrastructure modernization journey.  

Technologies