Cisco ACI MicroSegmentation

One of the advantages of SDN is that we can create and delete network configurations programatically, just like we create Virtual Machines. So we can build the development and testing environments on demand, and destroy them when they are no longer required. With ACI, this does not requiring anyone going box-by-box configuring network constructs. Instead, a program or script can talk to the APIC API and create, modify or delete complex network configurations, regardless of physical topology. You can also snapshot existing configurations … like you can snapshot a VM (… a promise long made by other SDN vendors, and long overdue … 

In this particular example ACI will be leveraging virtual machine attributes in order to provide segmentation needed to control the desired virtual machine communication in some instances, customers may add an identifier in their naming conventions to differentiate the VM role such as:

• DEV
• PROD
• External
• Internal

Then customer may create rules to allow or disallow traffic. For example DEV machines are not allowed to talk with PROD machines. ACI can help achieve by creating the necessary rules to block the desired communication.

In this lab we will be looking at how to implement microsegmentation by tweaking virtual machines attributes.

Assuming that you have an ACI tenant created we need one VRF and one Bridge Domain. Within the application profile define EPGs (End point groups) for web and application.

We need to allow uSeg-EPG segmentation in the Web EPG (acip01_epg_web) and update our domain

Once you have allowed MicroSegmentation in the aci_p01_epg_web. We need to create the uSeg EPGs policy

Then, we need to associate our USeg aci_p01_useg_web to our VMM domain aci_p01_dc3_vds 

We then need to define the rule for our USeg, in this particular case we are going to be using name as the VM attribute. Where POD01-WEB-SRV-01 and POD01-WEB-SRV-02 will not be able to communicate

ACI can provide different type of MicroSegmentation for different use cases. It is always import to understand the use case in order to configure ACI with the right set of properties.

————————————————————————————————————

Before exploring the details of the Cisco ACI Multi-Site, you should understand why Cisco uses both Multi-Pod and Multi-Site architectures and how you can position them to complement each other to meet different business requirements. To start, you should understand the main terminology used:

• Pod: A pod is a leaf-and-spine network sharing a common control plane (Intermediate System–to–Intermediate System [ISIS], Border Gateway Protocol [BGP], Council of Oracle Protocol [COOP], etc.). A pod can be considered a single network fault domain.
• Fabric: A fabric is the set of leaf and spine nodes under the control of the same APIC domain. Each fabric represents a separate tenant change domain, because every configuration and policy change applied in the APIC is applied across the fabric. A Cisco ACI fabric thus can be considered an availability zone.
• Multi-Pod: A Multi-Pod design consists of a single APIC domain with multiple leaf-and-spine networks (pods) interconnected. As a consequence, a Multi-Pod design is functionally a fabric (a single availability zone), but it does not represent a single network failure domain, because each pod runs a separate instance of control-plane protocols.
• Multi-Site: A Multi-Site design is the architecture interconnecting multiple APIC cluster domains with their associated pods. A Multi-Site design could also be called a Multi-Fabric design, because it interconnects separate availability zones (fabrics), each deployed either as a single pod or multiple pods (a Multi-Pod design).

Multi-Site allows you to interconnect separate Cisco ACI APIC cluster domains (fabrics), each representing a different availability zone. Doing so helps ensure multitenant Layer 2 and Layer 3 network connectivity across sites, and it also extends the policy domain end-to-end across the entire system. This design is achieved by using the following functional components:

Cisco ACI Multi-Site policy manager: This component is the intersite policy manager. It provides single-pane management accross sites, enabling you to monitor the health score state for all the interconnected sites. It also allows you to define, in a centralized place, all the intersite policies that can then be pushed to the different APIC domains for rendering them on the physical switches building those fabrics. It thus provides a high degree of control over when and where to push those policies, hence allowing the tenant change domain separation that uniquely characterizes the Cisco ACI Multi-Site architecture.

Intersite control plane: Endpoint reachability information is exchanged across sites using a Multiprotocol-BGP (MP-BGP) Ethernet VPN (EVPN) control plane. This approach allows the exchange of MAC and IP address information for the endpoints that communicate across sites. MP-BGP EVPN sessions are established between the spine nodes deployed in separate fabrics.

Intersite data plane: All communication (Layer 2 or Layer 3) between endpoints connected to different sites is achieved by establishing site-to-site Virtual Extensible LAN (VXLAN) tunnels across a generic IP network that interconnects the various sites. This IP network has no specific functional requirements other than the capability to support routing and increased maximum transmission unit (MTU) size (given the overhead from the VXLAN encapsulation). The use of site-to-site VXLAN encapsulation greatly simplifies the configuration and functions required for the intersite IP network. It also allows network and policy information (metadata) to be carried across sites.

The Inter-Site Network (ISN) requires only that the upstream router the ACI Spines connect supports OSPF and sub-interfaces. A sub-interface with encapsulation VLAN is used between the Spine interface(s) and the upstream ISN router interface(s). The only other requirement is for increased MTU support for the VXLAN encapsulation overhead